Краткая предыстория

Вообще, все началось давно. Настолько давно, что вряд ли остались свидетели holy wars тех дней, когда решалось — сколько же бит должно быть в байте.

Это сейчас нам кажется само собой разумеющимся, что 1 байт = 8 бит, что в байте можно закодировать 256 различных значений. Но когда-то было совсем не так. История помнит и семибитные кодировки, и шестибитные, и даже более экзотические системы (например — ЭВМ «Сетунь», которая использовала троичную логику, то есть один троичный бит — трит мог иметь три, а не два значения, для нее было справедливо соотношение 1 трайт = 6 тритам). Но если оставить в стороне всякую экзотику, то мэйнстримом все-таки были кодировки, в которых 6, 7 или 8 бит в байте.

Шестибитная кодировка (например — BCD) позволяла закодировать в одном байте 64 различных значения, что, как казалось, было вполне достаточно для кодирования алфавитно-цифровых символов, а «лишний» седьмой бит расширял кодировку уже до 128 символов.

Однако скоро восьмибитный байт стал общепринятым.

Автор топика Код, который приятно читать поделился своими правилами для написания хорошего кода, и в конце поинтересовался — «Какие ещё правила вы используете? Как сделать код читаемее?». У меня как раз под рукой есть документ из одной крупной английской конторы на которую я работал несколько лет назад (Delcam International plc), занимающейся разработкой CAD/CAM систем и в которой трудится несколько сотен, если не тысяч программистов из разных стран мира.

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

Часть из них могут показаться очевидными, часть весьма спорными, часть весьма полезными. Но в любом случае, это опыт крупной компании, и раз они были введены — значит на это были причины. Буду рад, если вы почерпнёте для себя что-то полезное, или внедрите часть из них в своём коллективе и это поможет вам эффективнее работать в команде.

Хороший код

К хорошему коду много требований: он должен быть оптимальным, у него должны быть юнит-тесты, его должно быть легко переиспользовать, он должен соответствовать код-стандарту компании и духу языка. А ещё его должно быть приятно читать.
Я бы хотел рассказать о правилах, которые помогают мне делать код читаемым.

Основное правило

Я считаю, что читаемым является код, в который можно не вчитываться.
То есть, пары-тройки строк дожно быть достаточно, чтобы сказать, что делает класс или метод. Ещё пары-тройки — чтобы примерно сказать, как он это делает.

Прочие замечания

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

Когда говорят, что устройство работает «как часы», то подразумевают, что это значит очень стабильно и надежно. Все мы мечтаем, чтобы с нашими «винчестерами» ничего плохого не случалось, но они любят отказывать самым непредсказуемым образом. Один такой свой диск я переделал, так что он теперь буквально работает как часы. Идея сделать устройство посетила после посещения выставок, где видел похожие рекламные девайсы. Мозг сверлила назойливая мысль — «неужели не смогу»?

Меня всегда смущал отчет от Tiobe, ну не похож он на правду. Ну хотя бы потому что Delphi на 9 месте, а javascript на 10, т.е. последнее и предпослениее места в top-10. И это в наше то время развития web 2.0, ну явно ведь должно быть в ином порядке. Ну и по остальным языкам все как то подозрительно. А что же на самом деле, что сейчас популярно у продвинутых программистов? А определить оказалось довольно просто, достаточно заглянуть на stackoverflow.com и посмотреть популярность тегов (они там четко к языкам прикреплены, есть куча модераторов отслеживающих правильность тегов)