Comments 26
Со всеми советами согласен, но больше всего меня подводил 5 пункт. Ибо нагородить всегда успеешь.
«Используйте оператор #define чаще. КАК МОЖНО ЧАЩЕ»
О_О Я вот наоборот читал что применение #define нужно снижать до «необходимого минимума» ибо иногда это приводит к недоразумениям. Пример:
define# MINUS 1 – 3
…
int x = 10 / MINUS ( = -3.333 а не -5 как ожидается)
По-моему так.
PS: Извините книгу не помню
О_О Я вот наоборот читал что применение #define нужно снижать до «необходимого минимума» ибо иногда это приводит к недоразумениям. Пример:
define# MINUS 1 – 3
…
int x = 10 / MINUS ( = -3.333 а не -5 как ожидается)
По-моему так.
PS: Извините книгу не помню
Ой нет! Получиться -7 О_О
PS: Вот видите к каким недоразумениям это может привести :)
PS: Вот видите к каким недоразумениям это может привести :)
Нада просто понимать, что делаешь.
Например полезная конструкция при разработке: define('DEBUG', 1);
Например полезная конструкция при разработке: define('DEBUG', 1);
Тут как в поговорке - "научи дурака богу молиться...". Естесственно, ко всему надо подходить с умом и врядли будет оправдано дефайнить 1-3. Но основные параметры программы - те значения, с которыми часто приходится "играть", все же стоит обозначить дефайном. В таком ключе эта мера - более чем к месту.
Это еще цветочки, гораздо хуже, если в параметрах есть выражение с автоинкрементом или еще что-то с побочным эффектом, а параметр подставлен в тело макроопределения пару раз, или когда приходится писать #define ... do {...} while (0) чтобы свести все к одному оператору и не нарушить блочность программы - а забыв об этом получаешь феерические ошибки... В общем, чем МЕНЬШЕ в программе #define, тем лучше для читабельности и отладки, правда изредка страдает быстродействие.
Вот вот! Вы как будто книгу цитируете :)
Современные компиляторы имеют настолько мощный механизм inline-подстановки, что кроме самых-самых тривиальных или критических к быстродействию случаев #define лучше не использовать. А в оригинале, НАВЕРНОЕ, имелось в виду, что лучше определять КОНСТАНТЫ через #define, чем писать их числами в коде. Но и тут тоже есть с чем поспорить. Ненавижу константы типа #define TEN 10 - как будто бы может быть иначе!
Вспоминается первоапрельская шутка, когда в рабочую версию проекта после предварительного бекапа в модуль определений включается что-то типа:
За правильность когда не ручаюсь, ибо пользовался дефайнами достаточно давно, но идея, я думаю, понятна.
Вообще кроме включения отладки по мановению волшебной палочки реального применения дефайнам не вижу. А уж за реализацию «константа» вне классов путём обработки препроцессором скрипта разработчикам PHP надо отрывать руки, ИМХО.
#define ("true","false")За правильность когда не ручаюсь, ибо пользовался дефайнами достаточно давно, но идея, я думаю, понятна.
Вообще кроме включения отладки по мановению волшебной палочки реального применения дефайнам не вижу. А уж за реализацию «константа» вне классов путём обработки препроцессором скрипта разработчикам PHP надо отрывать руки, ИМХО.
define# MINUS (1 – 3)
и всё путем
ах, да: пункт 6 :)
и всё путем
ах, да: пункт 6 :)
То что вы задефайнили, то и получили.
Дефайнить надо коректно.
Дефайнить надо коректно.
с первым согласен, всегда зыбваю что писал сам через месяц второй))
1. Будьте благоразумны – пишите комментарии.1. Комментарии должны пояснять действительно тонкие моменты. Так же приятно, когда откомментированы функции основных блоков кода, параметры процедур и ограничения на них. Но начитавшись о пользе комментариев, многие программисты начинают комментировать каждую строчку программы. Это бессмысленно, так как если в программе написано if (Counter == 0) то и без банального комментария "проверяем счетчик на ноль" любому понятно, что делает этот if. Для кого пишут такие комментарии? И какой более емкий комментарий можно написать к такому if-у? Никакого? Так и не нужно тогда ничего писать!
2. Более того, обилие комментариев к каждой строчке в большинстве случаев даже вредно - так как на практике у любителей таких комментариев они быстро начинают расходиться с реальностью. Пример: if (Counter == 0 || Counter > Limit) /* проверяем счетчик на ноль */
3. Я не призываю вообще убрать комментарии, но оставить их только к более и менее крупным блокам кода и функциям в целом. Построчные - только к нетривиальным местам в программе. В остальном коде умный и без комментариев разберется, а дураку и комментарии не помогут. "Лишние" комментарии не мешают, конечно же, если не расходятся с реальностью, но и пользы от них никакой. Только съедают время на свою поддержку при модификациях.
Честно мне кажется 6 советами тут не отделаешься! Я читал книгу (об этом я говорил выше) которая полностью просвещенна КАК надо писать код. Причем книга написана не графоманом. А реально по делу и коротко и все равно 400 страниц.
Он писал о том, КАК комментировать, что комментировать, зачем. Как тестировать, как отлаживать, как писать код, чтобы потом отлаживать было удобней. Как тестировать. И так далее. В общем, слишком много важных вещей чтобы описать все в 6 советах. ИМХО
Он писал о том, КАК комментировать, что комментировать, зачем. Как тестировать, как отлаживать, как писать код, чтобы потом отлаживать было удобней. Как тестировать. И так далее. В общем, слишком много важных вещей чтобы описать все в 6 советах. ИМХО
5. «Преждевременная оптимизация – корень всех зол», – Дональд Кнут (Donald Knuth).Автор цитаты - Хоар, а не Кнут. Кроме того, чтобы понять истинный смысл этой фразы, нужно сначала достичь своего предела в
ещё нужно отметить то что не нужно лениться и код хорошо форматировать(хотя это наверно тока новички таким грешат).
и ещё Крис както писал(хотя и не он это придумал) про использование кодов ошибок типа 0xDEADBEEF для удобной отладки без надобности заглядывать в исходные тексты
и ещё Крис както писал(хотя и не он это придумал) про использование кодов ошибок типа 0xDEADBEEF для удобной отладки без надобности заглядывать в исходные тексты
По поводу правильного написания кода очень рекомендую "Макконнелл. Совершенный код" (http://www.ozon.ru/context/detail/id/3159814/)
Прочитал от корки до корки и не пожалел ни на секунду
Прочитал от корки до корки и не пожалел ни на секунду
UFO just landed and posted this here
UFO just landed and posted this here
Пункт 2 - автор просто призывает избегать магических чисел.
Полностью согласен.
Поскольку занимаюсь олимпиадным программированием (3 человека пишут общий код за 1 компом) часто сталкивался с проблемой «умного» кода и переменных с диким названиями.
Дефайн тож очень полезный прием, чаще всего дефайню for:
#define forn(i, n) for(int i = 0; i < int(n); ++i)
#define forv(i, a) forn(i, a.size())
и пары:
#define mp(a, b) make_pair((a), (b))
Поскольку занимаюсь олимпиадным программированием (3 человека пишут общий код за 1 компом) часто сталкивался с проблемой «умного» кода и переменных с диким названиями.
Дефайн тож очень полезный прием, чаще всего дефайню for:
#define forn(i, n) for(int i = 0; i < int(n); ++i)
#define forv(i, a) forn(i, a.size())
и пары:
#define mp(a, b) make_pair((a), (b))
Sign up to leave a comment.
Шесть советов по написанию более понятного программного кода