Статьи

Внесите обработку всех ошибок в наиболее подходящий контекст. Если выходит проблема чтения/записи диска, ее нужно делать в том коде, который занимается доступом к диску. Для обработки данной ошибки может потребоваться сгенерировать другую ошибку, передав ее на более высокий уровень. Это говорит о том, что на каждом уровне программы ошибка должна быть точным описанием проблемы в … Подробнее…

Хорошие комментарии для самодокументируемого кода, несомненно, нужны, но ими дело не ограничивается. На самом деле рекомендуется стремиться избегать комментариев путем написания такого кода, где в них нет необходимости. Приемы написания самодокументируемого кода: Пишите простой код с неплохим форматированием. Выбирайте хорошие и подходящие имена. Разбивайте свой код на самостоятельные функции. Выбирайте содержательные имена типов, это очень … Подробнее…

Плохие программисты при выборе имени объекта: • Пишут одноразовый код, не до конца подумав его в погоне за скоростью. • Не думают о понятности своего кода. • Игнорируют естественную идиоматику языка программирования. • Не думают об общей картине и им не важен согласованность своего кода с проектом в целом. • Не стремятся в своих проектах … Подробнее…

Хорошие программисты при выборе имени объекта, учитывают такие факторы: • Понимают необходимость выбора имен и занимаются этой проблемой. • Не забывают о важности выбора правильного имени для каждого создаваемого объекта. • Видят главную картину и выбирают имена в рамках проекта (или же группы проектов). • Учитывают многие факторы: понятность, длину имени, контекст и т. д.

Старайтесь избегать в своих именах таких качеств, как: Неточность или обманчивость. Заумь или бессмыслица. Многословие. Двусмысленность или неясность. А лучше, выбирайте четкие имена, которые точны, понятны, конкретны, недвусмысленны, коротки. Рекомендуется использовать стандартные термины и принципы. Выбирайте подходящие слова из предметной области и используйте наглядные схемы составления имен.

Нужно избегать остроумных, но трудно запоминаемых сокращений, симпатичных аббревиатур, а также толковательногоприменения числительных. i18n (сокращение для слова internationalization) кажется полной ерундой. Поэтому всегда старайтесь подбирать осмысленные имена для своих переменных и т.д. к чему даете имя.

Не подбирайте имен, которые можно понять по-разному. Не выбирайте совершенно туманные имена типа value или data, если только в контексте не указывает точно, что они собойпредставляют. Избегайте неопределенных tmp или temp, если в этом нет нужды.Не создавайте локальные переменные с такими же именами, как объекты во внешней области видимости, если на это нет особых причин.Не … Подробнее…

Как бы просто не звучало, но помните, что имя нужно выбирать точно.Не нужно называть widget_table то, что не имеет никакого отношения к таблицам. Не нужно называть что-то widget, еслиэто контейнер для двух и более widget.Обычные орфографические ошибки – это сложное минное поле большой путаницы. Ищу переменную hello и нигде не могу ее найти. Оказалось, что … Подробнее…

Загадочность. Есть много вариантов создания непонятных имен. Акронимы и сильные сокращения вполне могут оказаться ненужными, а однобуквенные имена (вроде таких: z, q, b и т.д.) – слишком загадочными. Многословие. Избегайте очень коротких имен (тем более однобуквенных), но и не создавайте таких переменных, как сколько_груш_съел_перед_тем_как_начал_их_кушать. Ни пользы, ни развлечения.

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