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

[Utkin]

чем?

Временем на поиск подозрительного кода.

а я не говорил что буду переписывать с нуля

Это радует, но второй оппонент появляется редко, да я и не стараюсь его "уесть" мне просто интересны его аргументы, я допускаю, что не прав. Хотелось бы знать где.

[Пепел Феникса]

Временем на поиск подозрительного кода.

отступ итак отлично виден(особенно в С++, с отступами-табами), а при отладке(именно отладке а не пересмотре кода) там отлично ставиться бряк как на соответствующей части ветки условия/циклов, и при построчном выполнении войдет на строчку только в случае выполнения условия для захода в блок.
короче просто не вижу разницы.

[Utkin]

Речь шла не об оступе, а самостоятельном блоке .

короче просто не вижу разницы

Кесарю кесарево, Но разница есть, особенно при Иф и при While... Еще раз напоминаю никого ни в чем не обвиняю и ничего не заставляю... Возможно моих выразительных средств просто не хватает сообщить одним постом, чтобы без экспрессии и понятно без 10 постов возражений...

[Пепел Феникса]

Но разница есть, особенно при Иф и при While...

ну не вижу разницы я между этим:

if(s && s_own)
    delete s;

и этим:

if(s&&s_own)
{
    delete s;
}

хоть убейте...

PS: ну кроме двух фигурных скобок

[Utkin]

Чисто психологически - оператор воспринимается как независмый от If. Скобки явно указывают что не все так просто....

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

Тема об оформлении(стилях) кода. Каждый комментирует так, как ему удобно.
Комментарии - это отдельная темя. Главное не комментировать слишком многое и/или очивидное.

Вопрос в очевидности комментария к коду, равен стажу программиста. Для кого-то это будет верх очевидного, для другого это будет :-\

[Пепел Феникса]

Чисто психологически - оператор воспринимается как независмый от If.

я знал что я не нормальный, но теперь критериев больше.

если убрать отступ то да, плохо выглядит.

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

Utkin

Касательно комментариев - я тоже не комментирую Х:=1, но комментарий к этой строке есть, внезапно да?

Да ну... ничего внезапного... разумеется, ежу понятно, что здесь переменной x присваивается 1. Но смысл может быть совершенно в другом: например, это может означать: на таком-то порту, по такому-то контакту пойдёт ток силой 1 милиАмпер. А вдруг там чего сложнее? Ты, наверное, это имел в виду.

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

Не читал я просто пока ещё всю тему, а точнее сказать, не читал практически ничего.
Мне ранее хотелось уже поднять такую тему, а в момент публикации написанного мной в эту тему, у меня уже были серьёзные намерения. А что, если из этой писанины (моей) сделать что-то вроде пособие по оформлению кода для начинающих? Уверен, им будет полезно.

Идентификаторы должны быть удобными для чтения. Даже если они слишком длинны. Дабы не разжигать полемику - это ИМХО, и я готов объяснить почему.

Ты же здесь мне не возражаешь. Про удобочитаемость идентификаторов-то я и забыл. Что объяснять тут? Чем легче читается идентификатор, тем он легче запоминается.

Потому что Ваша ИДЕ не поддерживает свертку кода. Я не за и не против - удобство при необходимости. В Visual Studio в этом нет нужды.

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

Здесь я с Вами не согласен. Что такое Integer (будем говорить в терминах Дельфи, очевидно Вам это ближе)? В рамках алгоритма? Всегда ли это целое число? Ну другой пример - вычисление дискриминанта в рамках квадратного уравнения. Представьте школьника - итак какой тип использует школьник при вычислении дискриминанта - double, extended? Если Вы выберите один из них, то вы не правы. Ибо алгоритму пофигу на тип и это должно быть отражено в комментарии. То что Вы опишите будет стопроценто завязано на типе, а это не верно в корне. Знаю по себе - будучи школьником я решал квадратные уравнения не имея представления что такое double и что такое extended.

Здесь я не могу понять. Я ведь говорил, о НАЗНАЧЕНИИ переменной, причём тут тип? Я же выше писал, что это хорошо, когда название переменной отражает её назначение, о типе и речи не было, здесь предполагается, что всё хорошо в рамках некого "НАДТИПА", или даже типа. Школьнику, как и алгоритму, пофигу, что использовать (какой тип), согласен. Но, даже если речь идёт о более серьёзных программах, всё равно нелья однозначно сказать, какой тип использовать. Всё упирается в наши нужды. Single использует меньше всего памяти, как действительный тип, но Extended имеет самую высокую точность.

Кстати, все правила, сформулированные мной, ИМХО, можно применить и к другим языкам, разумеется, с некоторыми поправками.

[still_alive]

2Utkin
Давай на ты, мне надоело выкать, ибо моя невоспитанность берет верх

Если что будет не так, то поправь, я Дельфи уже 4 года не практиковал.

Что мы видим при первом поверхностном осмотре:
1) неудачные имена переменных
2) выдвигаем предположение, что локальные переменные начинаются с маленькой буквы, а данные-члены класса с большой
3) магическое число 8
4) непонятные (ненужные) развертывания циклов
5) шаманство с переменной длины, это можно сделать красивее
6) ненужные проверки типа true = true (if flag[i] = true вместо if flag[i])
7) я понимаю, что дельфи регистронезависим, но придерживаться одного стиля надо все-таки
8) проверка с 8 внутри цикла - есть подозрение, что можно вынести
9) exit - затрудняет читабельность, так как приходится искать или думать, чему же в этот момент равно result
10) большое кол-во exit в разных местах кода напрягает
11) два if можно менять на один

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

Я это имел в виду. Но поскольку я тогда проделал это за минуту примерно, то звиняйте если что

2Пепел Феникса

if (s && s_own)
    delete s;

Предлагаю убрать проверку на s. Зачем она здесь? delete нулевого указателя проверяет это сам. Кстати поэтому обнуление указателя после delete является хорошей практикой.

[Пепел Феникса]

9 и 10, это к сожалению недостаток Делфи.
в С-подобных просто

return false;

а в Делфи это приходиться заменять на

begin Result:=false;exit;end;

а если делать начальное значение Result, то по сути еще одна переменная у нас выходит.

ну убрал, да только не про это был вопрос с этим кодом.