Рекомендуемые правила оформления кода

[Сtrl]

Еще важно отличать индентацию от выравнивания. Первая делается с помощью табуляции, второе - с помощью пробелов.

[Человек_Борща]

Я, за имением лишнего времени, написал о своём стиле и правилах форматирования кода.

Оцените =)

Чур тапками не кидаццо

[Поправил косяки]

[MaTBeu]

Не сразу понял в чем там стандарты и правила кодирования.
Посмотрите для сравнения Стандарт кодирования Zend Framework (PHP)

[Utkin]

Очевидно же, что причиной переписывания кода является крайняя его запутанность, а не нежелание разбираться в нем. Степень запутанности - один из оценочных факторов при принятии решения - рефакторить или переписывать.

Он не запутан, а вполне нормален . Люди вон примерно догадались про что писано. А с Вами все ясно - нет желания думать самостоятельно. Малейшее отклонение от стандарта и все разрыв шаблона. Да просто нет вообще желания хотя бы смотреть на приведенный аргумент. Все переписать , ага + гигабайты кода .

[Ponkole]

Слышал что то про программы (или дополнения), редактирующие программный код, подгоняющие его под определенные рамки и структурируя его. Предлагаю составить программы для редакции текста кода под свой стиль.

[Utkin]

Предлагаю составить программы для редакции текста кода под свой стиль.

Гы, 5 километров текста пофигу + еще несколько страниц намекающих на инструменты документирования тоже не в счет...

[Человек_Борща]

Гы, 5 километров текста пофигу + еще несколько страниц намекающих на инструменты документирования тоже не в счет...

я ещё в своём *.doc'е рассказал об тулзе для d7 и ниже, и об тулзах для d2006 и выше, которыми пользуюсь сам уже не помню сколько времени. Форматированный код спасёт мир.

[Utkin]

Форматированный код спасёт мир

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

ЗЫ. Как бы не охота тебя разоочаровывать (как и других), но форматирование кода не спасет абсолютно ничего. Извини, но унылое го**о которое есть в книгах не прокатывает ибо:
а) зависит от команды - а стандарты Мелкософта ничто в мире (как и стандарты в других локальных командах)
б) устарело в момент выпуска книги - какое по счету издание? 5-е, 6-е? И не успеет в ногу со временем, как бы ты (извини, что на ты местами) не старался, как бы не старался автор ( хотя известно почему старается автор, угадай кстати, почему? Ведь он в курсе, что через год устареет)
в) как всегда нет собственного мышления, да трехтомные книги хороши как справочники, как источники, но есть одно, но - да почитатай сам. Они не учат мыслить самостоятельно, более того, там это вредно. После прочтения главы и ответов на вопросы в американских книгах у меня периодически возникают вопросы и внезапно на них нет ответа...

[Вадим Мошев]

Я вот тоже решил написать.
_____________


Я пишу на Delphi. За всё время работы с этим языком потихоньку сформировался свой стиль оформления кода (хотя, наверное, не до конца). При этом, я своей целью ставил не только повышение удобочитаемости кода, но и в какой-то степени снижение умственной нагрузки при его чтении.
Итак, что я могу посоветовать.

Комментарии, само собой разумеется. В книге у Бьярна Страуструпа написано, что комментарии к коду писать ничуть не легче, чем писать сам код. Не знаю, насколько это - правда, мне просто не доводилось ни разу писать такие программы, которые писал он, да и уровень и у нас – небо и земля. При написании комментариев к коду, я предъявлял к ним требования: чтобы, во-первых, было понятно, к какому блоку (куску) кода они относятся, а, во-вторых, чтобы границы между блоками были обозначены чётче. Таким образом, я могу разделить комментарии на разделительные и поясняющие.

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

implementation

uses BeforeTest, Main, StopTestConfirm, AfterTest;


{$R *.dfm}


var TimeIndicatorVisible, ICanExit: boolean;

//------------------------------------------------------------

Procedure AnalyzeAndRate;
// Эта процедура выполняет анализ полученных ответов
// и ставит оценку по выбранной шкале
var
    RightAnswersCount, j: byte;

begin
    код процедуры
end;


//========================================================

Procedure Tform2.ShowQuestion(const k: byte);

Здесь я использую символ тире для отделения того места, где описываются типы, объявляются глобальные переменные и т.д.
Знак равенства я использую для отделения подпрограмм друг от друга.

Внутри подпрограмм такого деления я не использую, а компоную отступы с поясняющими комментариями.
Прежде всего, я после заголовка подпрограммы пишу пояснение, для чего она нужна. Пример смотрите выше, например, процедура AnalyzeAndRate. Замечу, что чётких правил выбора между однострочными и многострочными комментариями у меня не сформировалось, посему у меня такой комментарий может быть каким угодного – одно- или многострочным.

Далее, когда я пишу сам функционал процедуры, поясняющими комментариями я пользуюсь, когда возникает необходимость пояснить, что делает тот или иной кусок кода. Здесь комментарий тоже может быть каким угодно, чёткого правила нет.
Комментарий следует писать так, чтобы он казался своеобразным «заголовком» комментируемого куска кода, то есть самый первый символ комментария находился левее всех символов комментируемого куска кода. Например:

// Нижеследующее будет выполняться, если выбран режим ввода своего ответа
        // с клавиатуры

            // Скрываем ненужные элементы
               LabelChoseYourVariant.Hide;

               RadioButton1.Hide;
               RadioButton2.Hide;
               RadioButton3.Hide;
               RadioButton4.Hide;
               RadioButton5.Hide;
               RadioButton6.Hide;

               CheckBox1.Hide;
               CheckBox2.Hide;
               CheckBox3.Hide;
               CheckBox4.Hide;
               CheckBox5.Hide;
               CheckBox6.Hide;

            // Показываем нужные элементы
                LabelTypeYourAnswer.Show;
                LabelTypeYourAnswer.Caption:=
                'Введите ответ с клавиатуры и нажмите кнопку ответить. ';
                If R.CaseSensitive then
                                    LabelTypeYourAnswer.Caption:=
                                    LabelTypeYourAnswer.Caption+ 'Регистр букв УЧИТЫВАЕТСЯ.'

                                  else
                                    LabelTypeYourAnswer.Caption:=
                                    LabelTypeYourAnswer.Caption+ 'Регистр букв НЕ УЧИТЫВАЕТСЯ.';

                EditYourAnswer.Clear;
                EditYourAnswer.Show;

В некоторых случаях поясняющий комментарий может располагаться не сверху, а справа, и как бы «лежать» на некоторой строчке. Например

if x > 0 
	then // Если переменная x больше нуля, вообще какой-то комментарий
	    begin
	    {здесь какой-то код}
	    {здесь какой-то код}
	    {здесь какой-то код}    
	    end;

Также такими комментариями я пользуюсь для того, чтобы описать поля какой-то записи:

type
	Student = record
			FullName: string; // ФИО студента
			Group: string; // Название группы, где он учится
			IsFined: // Флаг "отчисленности" студента, показывает, отчислен ли он
		  end;

[Ponkole]

Гы, 5 километров текста пофигу + еще несколько страниц намекающих на инструменты документирования тоже не в счет

Извиняюсь, только сейчас прочел труд Человека_Борща. Тоже пользуюсь СnPack дополнением, а вот о дополнении Formatter слышу впервые, даже не заметил его в ссылках, выданных поисковиком до написания этой темы.