Как перестать писать говнокод

Как по-простому перестать говнокодить

Я не буду давать советы о том, что следует грамотно продумывать архитектуру системы, применять шаблоны, использовать библиотеки и тому подобные вещи.

Всё это сложно, неочевидно и чревато долгими спорами.

Я дам несколько простых советов, следовать которым так же просто, как мыть руки перед едой.

Группируйте файлы

Используйте силу папок. Самых обычных папок. В которых лежат файлы. Мощнейщее средство для организации файлов вашего проекта. Если количество файлов в папке перевалило за десяток – пришла пора создавать вложенные папки. Впрочем, десяток – это уже много, достаточно пяти. Не важно, как группировать. Важно одно – в папке на должно быть больше пяти файлов.

Группируйте функции

Группируйте функции внутри файла. Большинство современных языков имеют средства для этого (pragma mark, region и т.п.). В вашем языке нет таких средств? Используйте комментарии. Неважно, по каким критериям группировать. Важно одно – функции должны быть сгруппированы, и каждой группе должно быть назначено имя.

Ограничьте размер функции

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

Ограничьте размер файла

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

Отделяйте функции друг от друга

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

Избавляйтесь от комментариев

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

Кэмел-стайл и Паскаль-стайл – зло

Используйте символ подчеркивания для разделения слов в названиях переменных и функций. В нормальном письме слова разделяются пробелами и знаками препинания. В языках программирования эти символы нельзя использовать в именах. Из всех форм записи многословных идентификаторов, наиболее близкий к естественному – использование подчеркивания вместо пробела.

Это простые и однозначные правила. Не нужно сильно чесать репу, чтобы им следовать. Просто попробуйте. И через некоторое время вы заметите, что эти несложные правила выстраивают ваш код в красивые и ясные архитектурные решения. Работать с написанным кодом становится легко и приятно.

Как не говнокодить?

Часто ищя решения какой-нибудь задачи я натыкаюсь на обсуждения, что это так называемый говнокод и поставленную задачу можно решить другим способом. Как правило такой код вполне рабочий, но к нему возникают такого рода предъявы. Почему так происходит и как этого избежать, может какие-нибудь рекомендации?

Что если задача не была поставлена (сформулирована), а код пишется?

а зачем он тогда вообще пишется?

Задача могла быть решена на 0.1% а код может быть хорошим, потому, что легко и дёшего дорабатывается.

А можно закрыть все потребности говнокодом, который решает задачу на 100%, но как только через N времени появится новая потребность в расширении, проще будет просто отказаться от такой работы.

Попытайся наговнокодить на чистoм Posix sh.

Чтобы решить не поставленную задачу. Такие авторы считают, что постановка задачи — лишний этап. Даже на лоре таких полно. Как ты оцениваешь такой код?

Если кратко, то в чем разница?

А ты попробуй и сам поймешь. Ногу острелить намного труднее.

Внимательно читать документацию. Обычно претензии бывают, когда что-то делается стандартной функцией в 1-2 строчки, а ты изобретаешь велосипед на 100

Дыры в безопасности. Например, твой код сломается, когда встретит в каталоге имя файла с пробелом.

Писать на bash что-то длиннее сотни строк (автогенерированный код не считается, как и приклеенный к скрипту блоб). В 99% случаев это значит, что надо взять другой язык.

Вкусовщина. Всегда найдётся кто-нибудь, кто назовёт тебя быдлокодером, какой бы ты код не написал. Не стоит принимать всё слишком близко к сердцу.

Чтобы решить не поставленную задачу.

То есть задача все равно сформулирована? Отсутствие приказа на исполнение не означает отсутствия задачи.

А можно закрыть все потребности говнокодом, который решает задачу на 100%, но как только через N времени появится новая потребность в расширении, проще будет просто отказаться от такой работы.

Ну и отлично. Раз не было задачи сделать программу, которая будет поддереживаться внуками через полвека, значит в этом не было и смысла. То, что вы назвали говнокодом — свою задачу успешно выполнило и было отправлено в утиль, как и любой другой устаревший продукт. Если бы кому-то понадобилось расширение через N времени — это входило бы в условия задачи.

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

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

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

Как перестать писать говнокод?

Здравствуйте! Три месяца назад меня взяли работать в небольшую организацию, для нужд которой необходимо написать приложени (под Android, пишу на Java). На собеседовании особых вопросов не задавали. Сказали, мол, приложение будет простенькое , учиться вместе будем и тд. Руководитель мой, программист C#, он мне задания и даёт. Т.к. база программирования у меня крайне слабая уповаю я, лишь на гугл. Со временем, понимание начинает приходить, мозги работать. Т.е. постоянно идет работа с поиском кода, его чтением, анализом, что непонятно сразу в доки, книжки, статьи. Как то раз даже нашел в городе программиста, и напросился на встречу, где он мне написал кусок кода, который меня спас от увольнения. Даже зарегистрировался тут и на стэковерфлоу. Но я пишу откровенный говнокод. Руководитель ругает меня за низкую скорость. И может иногда карательные меры предпринять, хоть и не смертельные. Я действительно неэффективно работаю. Напрашивается вывод, нужно увеличивать знания java core. И писать, писать, писать. Но после рабочего дня, если я его честно отрабатываю, откровенно не халтуря, то мои мозги не могут воспринят информацию, в нужном объёме. Мне код снится ночью уже. Чаще мой рабочий день это 12 часов, за которые я успеваю выжать себя как лимон, потратить время на отвлекающие факторы и что то написать, вернее «наговнокодить«. Проект двигается, разрастается и с каждым днем я понимаю, что это вавилонская башня.

Мне нужен Ваш совет, умеющие программисты. Какой то жизненный опыт, ваш. Как перестать говнокодить?? Спасибо!

Да в общем-то никак. Умение писать грамотный код придет со временем, если, конечно же, регулярно практиковаться. Для новичка (особенно если речь идет всего о трех месяцах опыта) говнокод и медленная скорость работы — это вполне нормальная картина. Ему просто неоткуда знать, как писать код грамотно и быстро (к сожалению этому не учат даже в институтах ). Со временем, если у новичка есть голова на плечах и желание развиваться, он будет накапливать положительный и отрицательный опыт, научится грамотно распределять свое время и усилия, и мало-помалу этот процесс сдвинется с мертвой точки. Главные условия — это регулярная практика и самообучение. Описанная вами картина очень хорошо знакома многим (читая ваши строки, вспоминал, что почти то же самое происходило и со мной) — срывы сроков работы, регулярные баги, любовь к костылям, повсеместный говнокод, нагоняи от начальства. Серебряной пули здесь нет, это болезнь роста. Она излечивается со временем при соблюдении вышеуказанных условий.

В любом случае хорошим подспорьем будет ковыряние в чужих исходниках (Гитхаб к вашим услугшам), чтение подходящей литературы («Совершенный код» Макконелла или «Рефакторинг и улучшение существующего кода» Фаулера). Поинтересуйтесь также такой вещью, как рефактринг — изучение его принципов способно помочь в понимании того, как следует писать код. Если вы пишете на C# в Visual Studio, то великолепнейшим помощником для вас может стать Resharper. Он способен разглядеть тысячу потенциальных проблем в вашем коде и просто облегчить работу. Также очень благотворно может повлиять наличие наставника, который мог бы что-то показать и объяснить. Хотя с этим обычно сложнее.

1. Разберитесь как правильно писать на Java: Thinking in Java, Effective Java.
2. Пишите код.
3. Читайте про хороший код: Clean Code, Beautiful Code, Code Complete, Implementation Patterns.
4. Пишите код.
5. Читайте чужой хороший код. Изучайте исходники популярных open-source продуктов. Разумеется, вы не сможете сразу отличить хорошие примеры кода от плохих. Но это даст вам пищу для размышлений и образцы для подражания (пусть даже и не лучшие). Получится своего рода бесплатный опыт: вам не пришлось тратить время на разработку и написание, вы смотрите уже на готовый код.
6. Продолжайте писать код. Перечитывайте материал из пунктов 1-3. Выкидывайте плохой код. Пишите еще. Не бойтесь рефакторить.
7. Будет отлично, если вы сможете учиться у других программистов и кто-то будет адекватно критиковать ваш код, например в рамках open-source проекта.
8. Читайте про проектирование, принципы SOLID, паттерны, тестирование. Постепенно вы научитесь отличать хороший класс от плохого.
9. Возвращайтесь к своему старому коду (даже полугодовалой давности). Обдумывайте, что в нем не так, что вы бы улучшили. Опирайтесь в дальнейшем на этот опыт.

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

Чаще мой рабочий день это 12 часов, за которые я успеваю выжать себя как лимон

Не думаю, что оно того стоит. Такая работа — путь к стагнации и разочарованию в профессии.

Три месяца назад меня взяли работать

А это вообще не срок. Все впереди. Главное не позволяйте работе довести себя до «творческого выгорания».