Концепция имен указателей

Ну, просто все эти венгерские нотации, идентификаторы, составленные из первых символов слов и сокращенные до <= 8 символов и т.п. - все то тянется из времен доса, когда все писалось в текстовом редакторе 80x25, который подсказывал только номер текущей строки/столбца и имя редактируемого файла.

 

Код надо писать так, чтобы комментарии в нем были вообще не нужны

 

Это всё для удобства и код должен быть дисциплинирован.

Не согласен, все же хороший код должен быть прокомментирован в специфических случаях.

Код (C++):

1.     // Диапазон исключая символы(не буквы) и цифры
2.     bool checkrange(const char ch)
3.     {
4.         if(ch < 0 || ((ch > 64 && ch < 91) || (ch > 96 && ch < 123)))
5.             return true;
6.         else
7.             return false;
8.     }

Согласитесь комментарий вносит ясность?

 

... таких, как пояснение сложного алгоритма. Но комментарии, рассказывающие о том, как надо читать имена переменных - это уже говнокод.

В этом говнокоде все стало бы яснее, если бы коды символов были заменены на литералы. Без комментариев

 

И вообще:
1. Для аргументов, передаваемых по значению, const не нужон.
2. Полагаться на то, что char это знаковый тип нельзя.
3. Без "else" код, как ни странно, будет работать точно так же, стало быть он там не нужон.

 

Вы сами себе уже противоречите.

Литералами тут не обойдешься, там чтобы выйти за 0, нужно целую портянку писать, что есть не комильфо.

Вот давайте только без переходов на личности и вбросов без подкрепления кодами.

 

1) Этот символ используется другой функцией и const там "нужон", хороший тон использовать как можно чаще const.
2) Можно, так как signed модификатор юзается неявно.
3) else не упущение.

 

1. Если туда он передается по ссылке, то там const и указываем. А иначе он и там не нужон. Хороший тон - использовать const там, где это имеет хоть какой-то смысл (например, сообщить компилятору, что внутри функции аргумент, передаваемый по ссылке изменяться не будет, что может поспособствовать построению более оптимального кода).
2. Если иного не указано в командной строке.

 

Я пишу сразу по принципу, принимаемые аргументы как const(кроме аргументов как те что mutable), if с else, etc, как черновую, потом уже когда все написано и работает начинается улучшение, то что лишнее убирается.

Вы же тело if, for, while начинаете с фигурных скобок?

 

Я заметил, потому и говорю, что так неправильно. Если аргумент передается по значению, то функция его и так изменить не может, т.к. работает со стековой копией; const здесь избыточен.

Если в теле больше одного выражения. Или если это условный блок с множеством else, хотя бы в одной из которых больше одного выражения.

 

Шо, опять? Будет char знаковым или беззнаковым определяется ключами компилятора. Ключами, которые возможно компилятору будешь прописывать не ты, а человек, использующий твой код.

 

Попадался на днях в эту ловушку, так как функция позже была дополнена.

И что? Руки для чего?

 

Один известный в своих кругах человек поставил все точки над i этим постом:
http://cellperformance.beyond3d.com/articles/2008/03/three-big-lies.html

 

Нет. А почему вы спрашиваете?

[added]
Обидели прям ( Я старый нервный ассемблерщик, я еще для Z80 на бумажке кодил)

 

Но ведь реально говнокод ))

Мой вариант (тоже не идеальный, конечно, можно еще вылизывать - но очень читабельный):

Код (Text):

1.  
2. bool non_character(char ch)
3. {
4.    return ch < 0;
5. }
6. bool uppercase(char ch)
7. {
8.    return ch >= 'a' && ch <= 'z';
9. }
10. bool lowercase(char ch)
11. {
12.    return ch >= 'A' && ch <= 'Z';
13. }
14.  
15. // бывший checkrange()
16. bool is_valid_character(char ch)
17. {
18.    return non_character(ch) || lowercase(ch) || uppercase(ch);
19. }
20.  

 

ol.,

Код (C++):

1. bool non_character(char ch)
2. {
3.    return ch < 0;
4. }
5. bool uppercase(char ch)
6. {
7.    return ch >= 'a' && ch <= 'z';
8. }
9. bool lowercase(char ch)
10. {
11.    return ch >= 'A' && ch <= 'Z';
12. }
13. // бывший checkrange()
14. bool is_valid_character(char ch)
15. {
16.    return non_character(ch) || lowercase(ch) || uppercase(ch);
17. }
18.  

Зачем здесь 3 версии функции? Ещё разнесите символьные константы для полноты в разные функции, совсем наглядно будет.

Так пишут новички. Есть такое правило золотое - не твори сущностей без нужды и я его придерживаюсь.

non_character что у вас делает? У меня она для проверки и кириллицы, не только латиницы.

Если продолжите в таком стиле писать, то больше не посчитаю нужным вам отвечать.

Потому что кто пишет на пайтоне они в основном змеиной нотации придерживаются, а вот из мира джава, джаваскрипт любители как раз таки верблюжей нотации. Плюсовики пишут по разному, но больше встречаю что на гитхаб, что в книгах, на форумах, либо сокращения, либо конкат, либо змеиную нотацию.

 

Что ж ты со своим const этого правила не придерживаешься?

 

Зачем повторять вопрос который уже имеет ответ?

 

Что-то я не припомню, чтобы ты публично признал свою ошибку

 

Признал бы, если это действительно было ошибкой.

Теперь ясно?