Тук зависи от школата. В новите практики променливите се дефинират при първа употреба и колкото може по-локални.

Така както Test42 го написа i-то съществува само в цикъла, тоест само където се ползва. Иначе си признавам доброволно, че и аз си дефинирам променливите в началото на блока. Но пък не отричам предимствата на "дефинирай, когато ползваш" стила.

Хм, може би, но явно са ме учили на по-строга дисциплина по отношение на променливите, иначе по мое мнение се губи в един момент края. А и reuse на пространството/регистрите може би е по-разумна политика, не на 100 места в машинния код да имам структура за работа, която после да се заеме от други неща и така...

точно такова дефиниране не е добра практика, защо не дефинирате експлицитно променливата на цикъла заедно с другите променливи а трябва да го правите във for цикъла?

Защо да я дефинирам извън for цикъла, ако извън него тя само ще ми пречи? Като я видя във for цикъла веднага ще ми стане ясно каква е и за какво е. Ако я дефинирам примерно в началото на метода тогава ще се чудя „за какво пък ще я използвам тази променлива“ а като стигна for цикъла ще се чудя „какво ли пък се е случвало с тази променлива досега и дали се е използвала за нещо“. Има практика променливите да се дефинират и инициализират възможно най-късно. Причината за нея е точно за да не мислиш за тази променлива преди да ти потрябва, както и да не се чудиш какво е ставало с нея и да трябва да се връщаш нагоре в кода за да видиш отново какво всъщност е ставало. Четимостта се увеличава, тъй като възможно най-малко мислиш за излишни променливи. Намалява се вероятността след време да се намести някой код, който неочаквано да промени стойността на променливата ти. Също нещо важно е, че ако решиш да разбиеш даден метод на по-малки това би станало доста по-лесно. Повече може да се види например в книгата Code Complete. В нея се говори за неща като variable span и variable lifetime и защо е добра практика да ги държим минимални.

Ами с това се свиква бързо. for примерът не ми се струва аналогичен. Освен това защо е неестествен - ами защото навсякъде пишат сравненията с константа подредени така. Което за мен е лошо обучение, защото самата операция е комутативна и не мога да си представя защо да прочета а == b е различно от b == a

Просто когато пишем такава конструкция интуитивно определяме по-важното нещо, тоест нещото, което ни интересува, за подлог. А от естествения език сме свикнали подлогът да е първи и затова очакваме това, което ни интересува, да е на първо място. Ако имаме промелива брой_хора и искаме да я сравним с 5, ако приемем брой_хора за подлог казваме „броят на хората е 5“ („броят на хората е равен на 5“), а ако приемем 5 за подлог това би било „5 е броят на хора“ („5 е равно на броят на хора“). Или пък „Цветът на небето е син“ срещу „Синьото е цветът на небето“ когато се интересуваме какъв е цветът на небето (примерно ако някой е задал изрично въпросът „Какъв е цветът на небето“). Второто също е правилно, но отнема малко повече време да се осмисли и не е първото нещо, което се очаква. Дори в математиката когато имаш тъждество или наравенство, при които имаш едно неизвестно от едната страна, обикновено неизвестното се пише отляво, тъй като по този начин се набляга на него и по-бързо написаното става ясно.

Да, но това си е валидна конструкция и може да искаш да я използваш нарочно и понякога прави кода по-четим. Така че не е правилно да се прави на грешка, а ако е предупреждение, лесно може да се пропусне.

Обикновено практиката е когато искаш да използваш такава конструкция да я поставиш в допълнителни скоби за да си личи. Тогава компилатора не извежда предупреждение. Така че това не е проблем.

Тук си напълно прав и това е най-коварното - хората понякога спират да внимават. Имахме един случай такъв, в който присвоената стойност (идваше от хардуер), само веднъж на няколко часа работа беше грешна. И това водеше до грешно поведение в съвсем друга част на кода....

Случва се и затова е необходимо добро тестване — от малки програмни единици до по-големи модули, особено за хардуер. Разбира се няма как тестовете да покрият абсолютно всички случаи. Но според мен четимостта на кода има по-голяма полза от ползата от избягване на такава грешка.

Аз не казвам че предложеният ми метод е идеален, казвам че употребата му е полезна.

Идеално би било в C/C++ оператора за присвояване да е малко по-различен - да кажем като Паскал...

И аз не отричам тази практика. Просто не е толкова еднозначно да се каже дали е добра или лоша. За мен доводите против нея са по-силни.

Защо да я дефинирам извън for цикъла, ако извън него тя само ще ми пречи? Като я видя във for цикъла веднага ще ми стане ясно каква е и за какво е. Ако я дефинирам примерно в началото на метода тогава ще се чудя „за какво пък ще я използвам тази променлива“ а като стигна for цикъла ще се чудя „какво ли пък се е случвало с тази променлива досега и дали се е използвала за нещо“. Има практика променливите да се дефинират и инициализират възможно най-късно. Причината за нея е точно за да не мислиш за тази променлива преди да ти потрябва, както и да не се чудиш какво е ставало с нея и да трябва да се връщаш нагоре в кода за да видиш отново какво всъщност е ставало. Четимостта се увеличава, тъй като възможно най-малко мислиш за излишни променливи. Намалява се вероятността след време да се намести някой код, който неочаквано да промени стойността на променливата ти. Също нещо важно е, че ако решиш да разбиеш даден метод на по-малки това би станало доста по-лесно. Повече може да се види например в книгата Code Complete. В нея се говори за неща като variable span и variable lifetime и защо е добра практика да ги държим минимални.

....

Хм, вие мислите като разработчик на даден език, не мислите като човек, който знае че накрая този код, който е написал ще трябва да се доведе до изпълним код

Хм, вие мислите като разработчик на даден език, не мислите като човек, който знае че накрая този код, който е написал ще трябва да се доведе до изпълним код

Донякъде може би да. Гледам да наблягам на по-добър код от гледна точка на четимост и дизайн, тъй като смятам, че ползите от това са повече. Но винаги мисля и имам едно наум какво се случва отдолу. Когато то не ми хареса и видя, че може да се подобри достатъчно, че да има смисъл, се опитвам да измисля по-различна абстракция. А и компилаторите в повечето случаи ще оптимизират променливите, където и да са дефинирани в метода. Или поне разликата няма да е голяма. Ако няколко пъти в метода дефинирам променливата i заради цикли то най-вероятно компилаторът сам ще открие това и ще я преизползва.

Иначе практиката е показала, че местата в един софтуер, които се нуждаят от оптимизация, са малък процент от целия код и е по-важно усилията да бъдат насочени към тяхното откриване.

eхоо какво мислите за тази книга ще ме въведе ли Първи стъпки в програмирането на C/C++ , ще ми помогне ли???

eхоо какво мислите за тази книга ще ме въведе ли Първи стъпки в програмирането на C/C++ , ще ми помогне ли???

Тука,малко стана offtopic и се отплеснаха от твоя първоначален въпрос,но е така,когато група стабилни хора обсъждат една тема...Книгата,която zerocool2 ти предложи е добра.Лично аз не съм я чел,но са ми казвали хубави неща.Но сам виждаш има много тънкости,особено с C/C++.

(0 == x) или (x==0)?!?На пръв поглед нещо толкова дребно и нищожно,а пък може да ти прецака цялата програма,така че някои неща си се учат,почти цяла кариера и с една книжка нищо няма да стане...

Тука,малко стана offtopic и се отплеснаха от твоя първоначален въпрос,но е така,когато група стабилни хора обсъждат една тема...Книгата,която zerocool2 ти предложи е добра.Лично аз не съм я чел,но са ми казвали хубави неща.Но сам виждаш има много тънкости,особено с C/C++.

(0 == x) или (x==0)?!?На пръв поглед нещо толкова дребно и нищожно,а пък може да ти прецака цялата програма,така че някои неща си се учат,почти цяла кариера и с една книжка нищо няма да стане...

добре ,аз ще взимам доста книги и ще чета ,но питам дали тази книга "Първи стъпки в програмирането на C/C++'' дали ще ме въведе,дали ще се науча как да пиша кодове(програми)каде и такива начални глупости :]

добре ,аз ще взимам доста книги и ще чета ,но питам дали тази книга "Първи стъпки в програмирането на C/C++'' дали ще ме въведе,дали ще се науча как да пиша кодове(програми)каде и такива начални глупости :]

Типично за твоята възраст, повтаряш един въпрос по 10 пъти! Вече ти се отговори на него!

И това, дали ще се научиш да пишеш кодове, и "такива глупости" зависи изцяло от теб.

Редактирано 11 април 201214 г. от Viiipeer (преглед на промените)

Типично за твоята възраст, повтаряш един въпрос по 10 пъти! Вече ти се отговори на него!

И това, дали ще се научиш да пишеш кодове, и "такива глупости" зависи изцяло от теб.

off:

Прав сте,но не намествайте възрастта...

off:

Прав сте,но не намествайте възрастта...

Нищо лично, просто така изглежда отстрани. Извинявай, ако съм те обидил.

Нищо лично, просто така изглежда отстрани. Извинявай, ако съм те обидил.

Не съм се обидил.В конкретния случай,за конкретния потребител сте прав,но ме ми харесва поставянето на всички 14 годишни(или друга възраст) под един общ знаменател

добре добре..ясно не е нужно от грубостии..

Между другото и от ТУКА може да учиш.

Книгата,която искаш да прочетеш не е написано за начинаещи. И затова ако искаш да научиш програмиране от нулата тази книга (Програмиране на С++. Част първа) не е за теб.

На Бисерка Йовчева и Ирина Иванова има една книга "Първи стъпки в програмирането на C/C++", тя е много добра за начинаещи. Подробно е обяснено как да пишем, компилираме, тестваме , дебъгваме кода си.

Взех си тази книга ,но тук гледам пише за алгоритми и такива.Има задачи вътре ,но как да ги направя като не знам каде как да пиша и ползвам код

Взех си тази книга ,но тук гледам пише за алгоритми и такива.Има задачи вътре ,но как да ги направя като не знам каде как да пиша и ползвам код

В книгата всичко е обяснено! Как да пишеш, къде да пишеш, от къде да свалиш IDE , как да я използваш този IDE и т.н.

Редактирано 27 април 201214 г. от zerocool2 (преглед на промените)

В книгата всичко е обяснено! Как да пишеш, къде да пишеш, от къде да свалиш IDE , как да я използваш този IDE и т.н.

да ,но не е много лесно да се разбере в началото мисля да пропусна малко тези алгоритми.Но вие ще кажете да не пропускам и да чета на ред или ?

Редактирано 27 април 201214 г. от r0ssk0o (преглед на промените)

да ,но не е много лесно да се разбере в началото мисля да пропусна малко тези алгоритми.Но вие ще кажете да не пропускам и да чета на ред или ?

АЛгоритмите са основата на програмирането. Без тях си просто машинописка

АЛгоритмите са основата на програмирането. Без тях си просто машинописка

а какво са алгоритмите с две три думи казано ?

а какво са алгоритмите с две три думи казано ?

описана последователност от действия за извършване на дадена работа

описана последователност от действия за извършване на дадена работа

смисъл това е нещо като азбуката на програмирането.,Аз като гледам по форума с това програмиране само задачи..а аз искам да разбера как да направя програма и да почна малко по малко сега ще почна да чета тази книга от началото

смисъл това е нещо като азбуката на програмирането.,Аз като гледам по форума с това програмиране само задачи..а аз искам да разбера как да направя програма и да почна малко по малко сега ще почна да чета тази книга от началото

не е азбука, фундамент, основа.нещо на което се гради програмирането. представете си че не знаете как се умножават две числа и нямате оператор или функция в езика. която да го прави. Как ще умножите две числа тогава? А ако знаете какво е произведение на две числа ще можете да и го направите сам

не е азбука, фундамент, основа.нещо на което се гради програмирането. представете си че не знаете как се умножават две числа и нямате оператор или функция в езика. която да го прави. Как ще умножите две числа тогава? А ако знаете какво е произведение на две числа ще можете да и го направите сам

oхх..невероятно сложно ми изглежда.Нямам прецтава как ще ги науча тези неща.

Ето книги за алгоритми: The Art of Computer Programming, Introduction to Algoritmhs 3rd Edition (много е трудна). Потърси ги из нета има ги като безплатни pdf файлове.

oхх..невероятно сложно ми изглежда.Нямам прецтава как ще ги науча тези неща.

никой не е твърдял че програмирането е лесно

Аз съм си взел книга имам си,но просто ми изглежда ужасно трудно.