Оформление кода
При написании программы на любом языке следует придерживаться какого-нибудь соглашения об оформлении кода. Соглашение, или стандарт, описывает, где и как надо ставить переносы строк, какие отступы делать для блоков кода, и так далее.
Зачем нужны соглашения об оформлении кода?
Если поначалу кажется, что оформление кода по стандарту - не так уж важно, то скажу следующее: около 80% времени работы над программой составляет поддержка. То есть, 80% уходит на поиск ошибок, на мелкие исправления и добавления новых функций. Другими словами, 80% времени приходится копаться в существующем коде. А программный код средних и больших проектов почти наверняка будет обслуживаться уже не одним человеком, а по крайней мере несколькими.
Поэтому так важно, чтобы каждый программист в отдельности придерживался одного стандарта оформления, принятого в данной команде разработчиков. Если же ваша "команда" состоит лишь из одного человека, то даже в этом случае необходимо придерживаться стандартов, ведь по прошествии времени самому придётся возвращаться к старому коду, пытаясь вспомнить, как он работает.
Сравните два отрывка одного и того же кода, оформленного по-разному. Один из них оформлен абы-как, а другой (угадайте, какой :)) - с использованием соглашения об оформлении кода "Java Coding Conventions". Какой из них проще понять?
public String toString() {
int len = this.end - 0;
char[] ss = new char[len];
for (int i = 0; i < len; i++) {
ss[i] = this.cc[this.cci[i]];
}
return String.valueOf(ss);
}
public String toString()
{
int len=this.end; char[] ss=new char[len];
for(int i=0;i<len;i++)ss[i]=this.cc[this.cci[i]];
return String.valueOf(ss);
}
Общепринятые соглашения об оформлении кода
Почти в каждой крупной организации или группе разработчиков есть свой стандарт оформления кода. Один из стандартов, предложенный Sun для программирования на Java - "Java Code Conventions", следуя которому, получается весьма компактный, но в то же время прекрасно читаемый код. Java Code Conventions во многом применимы и для других языков, например, PHP.
В программном коде для отступов Java Code Conventions разрешает использовать как пробелы, так и символы табуляции. Однако, практика показывает, что отступы пробелами более "надёжны" в смысле переносимости кода. Например, код, отформатированный только пробелами, можно переносить из одного проекта в другой без потери форматирования, даже если в настройках разных проектов размер символа табуляции задан разный.
Во многих средах разработки по умолчанию сконфигурирован размер символа табуляции, равный четырём пробелам. Это, я убеждён, в корне ошибочно. Исторически, символ табуляции занимает 8 пробелов от начала строки. Когда редактор вместо 4 пробелов ставит в файле символ табуляции, то открыв этот же файл любым другим редактором, отображающим "стандартные" 8 символов на табуляцию, получим свалку неформатированного кода.
Это аукнется, когда изменения в программу придётся вносить не любимым редактором в любимой тонко настроенной IDE, а каким-нибудь Far или обычным блокнотом, в полевых условиях.
Существует так называемая "венгерская нотация", предписывающая давать названия переменным и членам классов с использованием префиксов, указывающих на тип переменной, например:
int m_iCount; LPCTSTR m_lpszName;
Польза венгерской нотации - под вопросом, поскольку типы переменных могут часто меняться, особенно при активной разработке, да и вводить каждый раз конструкции вроде "m_lpszName" вместо "name" - удовольствие сомнительное.
Командная работа
В случае командной работы над проектом, какие бы ни были выбраны соглашения об отступах, переносах строки и прочих нюансах оформления кода, их по возможности следует хранить в свойствах проекта, чтобы при использовании системы управления версиями (SVN, GIT) эти настройки автоматически оказались бы у каждого разработчика.
В Eclipse довольно тонкие настройки форматирования можно задать как на уровне Workspace, так и в самом проекте. В случае совместной работы, настройки следует делать именно в проекте.
Автоформатирование
В идеале, стандарт оформления кода должен обеспечиваться самой средой разработки. Если нет внешних факторов, навязывающих какие-то особенности оформления, то все настройки его можно сконфигурировать в IDE, в которой вы работаете. Современные среды разработки умеют форматировать исходный код в соответствии с указанными настройками. Это позволяет не заморачиваться на форматировании, а дать команду IDE самой отформатировать код. Это можно сделать как для небольшого фрагмента, так и для всего файла. Автоформатирование средствами IDE - очень полезная возможность, которой следует пользоваться.
Обычно форматирование исходника вызывается правым кликом по тексту программы в IDE, а дальше - выбираем пункт в выпадающем меню. Например, в NetBeans - Format.
При командной работе настройки форматирования должны быть доступны через систему управления исходниками всем членам команды, поэтому и автоформатирование будет давать одинаковый результат.
