Комментарии 30
"стиль мой настолько неизвестен" - то есть автор хочет сказать, что pylint на его коде кучу предупреждений выдаст?
if, while, for и т.д. - не операторы, а ключевые слова. И выражение if( a > 1 ) выглядит больше как вызов функции. Короче, не согласен. Тем более, что он ссылается в начале к естественному языку, так вот в естественных языках слова в скобках никогда не отделяются пробелами от скобок.
И вообще, какая разница, насколько хорош или плох данный стиль, если в большинстве организаций принят свой.
Далее, в примерах по рестилизации он грубо меняет сам код, а это уже вообще не про стиль.
Про операторы - это ко мне больше. Текст и так был большой, где-то его можно еще сократить, но не хотел отходить от оригинала. Я думаю, если поменять в этом тексте слово "оператор" на "ключевое слово", смысл не особо изменится.
В угоду лучшей видимости кода автор, всё же пренебрёг правилом "должно быть как естественный язык", тем более, что он поясняет это целостностью оператора (функции), в случае, если "прилепить" скобку к ключевому слову (имени функции).
Ну вот, например, из последнего:
Про организации - сто процентов, Ваша правда, но подкорректировать личный стиль кода никто не мешает. На скриншоте тоже видно, что у меня нет возможности быть "адептом стиля deWiTTERS", но что-то можно использовать. Вы же не используете стиль кода, которым писали в своей первой организации, во всех последующих?
А про изменение кода - это его профдеформация, как программиста. Я, например, часто не могу пройти мимо кода в продуктах своей организации, если там откровенный колхоз. Ну, правда, не всегда получается прямо хорошо сделать - тронешь где-то в одном месте, посыпется в другом. Надеюсь понятна моя мысль.
Я думал, что первые комментарии будут как раз про ВерблюжьюТему и тему_с_подчёркиваниями :)
По поводу стилистики наименования элементов в разных языках — немного отдаёт самозатворничеством. Не считаю моветоном использование в своей программе стилистики, которая устраивает меня. Оговорюсь, что это не касается продуктов, которые разрабатываются командой, особенно там, где есть соглашение о коде. В своих работах пользуюсь подчёркиваниями в abl, в том числе (в Java пробовал - нормально выглядит). Хотя в abl чаще пользуются вообще, венгерской нотацией.
Как и большинство изучающих языки программирования, стараюсь читать документацию. Если в документации, создатели языка говорят о регистронезависимости операторов или ключевых слов - я пользуюсь этой информацией. Ну, скажем так, я не адепт больших букв в запросах к БД. Когда погружен в язык, нет необходимости выделять ключевые слова прописью, особенно с текущим уровнем различных редакторов и IDE. Да, есть огромное количество мест, где: не то, что цвета, вообще вёрстки толком нет — но и там, я знаю, большие буквы в select'е не становятся панацеей для удобства. Всё равно придётся прочитать всё, чтобы понять, что происходит, если код не твой. Если твой, то точно: большие буквы в тексте не ускорят процесс понимания и фиксации. Надеюсь, понят правильно.
Насчёт реформаторов - полностью с Вами согласен. Оригинального мало, но есть полезное. Я не защищаю, в данном случае Коэна Уиттерса, ну просто для себя нашёл некоторые полезные моменты, которые применил на практике.
Ну к слову, как-то привык, что верблюжьяТема и PascalCase это немного разные вещи.
В статье описывается просто code style. От названия статьи ожидания чего-то большего, про идеологию и методологию кодинга. А тут даже мантр design patterns нет...
В статье много полезных советов, но в целом — это субъективный подход одного автора к программированию и можно оспорить как минимум 50% его рекомендаций.
Также немного смущает его стиль подачи: вместо «я предпочитаю делать так» он директивно и безальтернативно утверждает «должно быть так».
Также не встретил в статье упоминания о моём любимом и крайне полезном стиле «табличной» записи повторяющихся однотипных фрагментов кода — этот метод экономит кучу времени и позволяет легко выявлять трудноуловимые ошибки.
Где про него можно почитать?
Про него можно почитать в моём комментарии :)
В коде используется табуляция в 2 пробела. Если в коде встречаются однотипные фрагменты, то они «форматируются» в виде таблицы (однотипные элементы один под другим), несмотря на тип кода — это могут быть массивы, функции, просто фрагменты кода или любые другие структуры.
Это:
Позволяет экономить место на экране и видеть больше кода
Сразу выявляется «паттерн» однотипных участков и самого алгоритма
Становится видно как уменьшить и оптимизировать код
При табличной записи становятся видны трудноуловимые ошибки в названиях переменных и их значениях
Единственное ограничение — ширина экрана — не стоит делать километровые листинги в ширину. Также этот метод нужно применять без фанатизма и только там, где это уместно.
Пример:
void sendHtmlAnswer(EthernetClient cl) {cl.println(makeAnswer(F("text/html")));}
void sendCssAnswer (EthernetClient cl) {cl.println(makeAnswer(F("text/css")));}
void sendJsAnswer (EthernetClient cl) {cl.println(makeAnswer(F("application/javascript")));}
void sendPngAnswer (EthernetClient cl) {cl.println(makeAnswer(F("image/png")));}
void sendJpgAnswer (EthernetClient cl) {cl.println(makeAnswer(F("image/jpeg")));}
void sendGifAnswer (EthernetClient cl) {cl.println(makeAnswer(F("image/gif")));}
void sendXmlAnswer (EthernetClient cl) {cl.println(makeAnswer(F("text/xml")));}
void sendIcoAnswer (EthernetClient cl) {cl.println(makeAnswer(F("image/x-icon")));}При обычном подходе этот код растянулся бы на несколько экранов вниз и слился бы в кашу без размера и структуры. И в этом коде нереально было бы заметить, например, ошибку в типах файлов.
За что я люблю Хабр и рад стать частью этого комьюнити. В комментариях, зачастую, можно найти огромное количество полезной информации и именно из-за Хабра я стал больше читать комментариев, под разными постами, на разных ресурсах.
Вам огромное спасибо за способ записи. С разбега сразу не гуглится. На Вашем примере отодвинул бы правые скобки к третьей строке, чтобы в глаза сразу бросился параметр функции. Простите за душность))
Почему автор пишет "Определение функции (definition)"
Но предлагает писать "if( x != y )"?
Написанное должно быть абсолютно понятным настолько, насколько это вообще возможно. - какой смысл в этом правиле? это как в тз требование "дизайн должен быть приятен и удобен пользователю" - признак дилетанта, неумеющего писать тз
Но в комбинации с префиксом "my_" мы получаем безумие, типа "my_is_old" или "my_has_children". Я так и не смог найти хорошего решения для этой проблемы, если у вас есть предложения, пожалуйста, оставьте комментарий к этому посту.
i_am_old и i_have_children. Все просто.
Я подозреваю, что автор имел ввиду, что если мы члены класса называем с префиксом my_, но при этом член класса - поле булевского типа (которые, по задумке автора стоит именовать с префиксами is_ или has_), то получается каша. Если принять во внимание Ваше предложение, получается, что для натуральности кода как языка - отлично, для понимания: что перед нами, переменная, поле класса, какого типа - неоднозначно.
Да, есть еще контекст, но тогда система его вроде не работает, получается))
Code style, среди прочего создаётся и для упрощения коллективной работы, в том числе, вводятся правила, которые уменьшают или полностью исключают изменения соседних строк. Отсюда всевозможные правила про висячие запятые, и запрет колоночного выравнивания.
А тут оно цветет пышным цветом. Но стоит вам добавить ещё одно свойство в класс, чуть более длинное, чем имеющиеся и вот, для поддержания красоты нужно менять несколько соседних строк.
В итоге ваш blame становится бессмысленным, а поиск через него первоначального коммита превращается в занимательный квест, а мерджи и число строк требующих ревью растёт непомерно.
Согласен, в коллективной работе code style должен учитывать особенности кода продукта, разрабатываемого командой.
Но для личного code style оно вполне себе может работать.
По идее, blame (должно быть) можно настроить так, чтобы он не считал чисто-пробельные внутристрочные модификации за полноценные и при обнаружении таких продвигался глубже по графу коммитов.
Я пишу «должно быть», потому что на вкус и цвет все фломастеры VCS разные, но в git blame это ключик -w, например.
Буду знать, что если скобки от содержимого этих скобок отделяли пробелами, то это не что-то странное, а deWiTTERS
Дао Кодинга (о стиле написания кода)