mfp: Writing less code: The "else" statement

[Blog bot]

Источник: http://blogs.msdn.com/mfp/archive/20...statement.aspx
==============
Source code is written once; and read over and over again. So make sure it is easy to read and understand.
I keep seeing a poor coding practice. I see it in production code, in test code, in X++ code, in C# code, in C++ code, in examples on the web, when interviewing candidates. I see it where ever I look. It is a practice that adds unnecessary complexity to source code, it make the source code harder to read, and harder to write. And what disturbs me the most is, how easy it is to avoid.
Take a look at this simple code:
<DIV class=source>boolean isNegative(int value)
{
if (value

[mazzy]

это замечательный призыв.

надо учитывать только две вещи:
1. корректная работа при обработке исключений
2. корректная работа внутри транзакционных скобок ttsbegin-ttscommit/ttsabort

Поэтому без-else-овую оптимизацию, по-моему, рационально делать только в простейших случаях, когда в каждой ветке делается return.

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

int foo(int bar)
{
    if ( /*expr1*/ ) throw /*some exception*/; 
    if ( /*expr2*/ ) return 1;
    if ( /*expr3*/ ) return 2;
    if ( /*expr4*/ ) return 3;

    doSomething or throw /*some exception*/;
}

а не так, как предлагает автор блога

См. также книгу Мартина Фаулера про Рефакторинг существующего кода
http://www.ozon.ru/context/detail/id...?partner=mazzy

или скачать эту книгу бесплатно, если предпочитаете читать в электронном виде
http://www.proklondike.com/contentview.php?content=258

[mono]

Цитата:

Сообщение от mazzy

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

int foo(int bar)
{
    if ( /*expr1*/ ) throw /*some exception*/; 
    if ( /*expr2*/ ) return 1;
    if ( /*expr3*/ ) return 2;
    if ( /*expr4*/ ) return 3;
 
    doSomething or throw /*some exception*/;
}

а не так, как предлагает автор блога

Даже в таких простейших случаях код должен выглядить так, как рекомендуют Best Practices, a не так, как предлагает mazzy.

Eсли не нравятся Best Practices - напишите свою Аксапту, с блекджеком и шлюхами.

[belugin]

Цитата:

Сообщение от mazzy

а не так, как предлагает автор блога

Я не вижу, чем это отличается от его примера, кроме скобок и переносов.

[mazzy]

Цитата:

Сообщение от belugin

Я не вижу, чем это отличается от его примера, кроме скобок и переносов.

только скобками и переносами и отличается.
тема блога - как сделать текст более читабельным для человека за счет отказа от "ненужных" else

[kashperuk]

Хм. Я считаю, что Best Practice - это конечно хорошо, но это не панацея.
И если код получается более читабельным (объективно) при небольшом нарушении BP, то так тому и быть.

[glibs]

Цитата:

Сообщение от kashperuk

...
И если код получается более читабельным
...

А еще иногда код приходиться править (для расширения функциональности). А еще бывает задача переноса на более свежий СП модифицированного кода. Именно поэтому рекомендуется ставить после IF скобки, даже если за ним следует один оператор всего. Чтобы свой кусок кода можно было просто и быстро вставить, нормально при этом откоментировав. Это не я придумал. Просто взял на вооружение. Видел нелепые и обидные ошибки на невнимательность, связанные именно с этим примером при модификации чужого кода. А не ошибается только тот, кто ничего не делает. Значит это просто лишний повод.

Сравните.

...
if (x < 0) throw error ("Error");
if (x == 0) return true;
...

и

...
    
// GLIBS: Some modification -->
// if (x < 0) throw error ("Error");
if (x < 0)
{
    this.doSomething();
    throw error ("Error");
}
// GLIBS: Some modification <--
if (x == 0) return true;
...

И следующие два примера.

...
if (x < 0)
{
    throw error ("Error");
}
if (x == 0)
{
    return true;
}
...

и

...
    
if (x < 0)
{
   // GLIBS: Some modification -->
   this.doSomething();
   // GLIBS: Some modification <--
   throw error ("Error");
}
if (x == 0)
{
   return true;
}
...

Если не комментировать — крышу сорвет при попытке разобраться в изменениях в коде (при том же переходе на новую версию, например, или при изучении чужих модификаций).

Если комментировать, то очень тяжело пользоваться функцией сравнения кода.

Так что mono прав, IMHO. А ВР нужно соблюдать.

[mazzy]

Вот ведь тема эволюционировала...

Цитата:

Сообщение от mazzy

Поэтому без-else-овую оптимизацию, по-моему, рационально делать только в простейших случаях, когда в каждой ветке делается return.

Цитата:

Сообщение от mono

Eсли не нравятся Best Practices - напишите свою Аксапту, с блекджеком и шлюхами.

Цитата:

Сообщение от glibs

А ВР нужно соблюдать.

BP нужно расширять и делать более интеллектуальным.

glibs, я же написал "только в простейших случаях, когда в каждой ветке делается return.". Если вставляется оператор до return'а, а программист не проконтролировал скобки, то... это скорее говорит о неопытности программиста, нежели о Best Practice.

Цитата:

Сообщение от glibs

Если не комментировать — крышу сорвет при попытке разобраться в изменениях в коде (при том же переходе на новую версию, например, или при изучении чужих модификаций).

А чтобы было легче разбираться с проапгрейдженным кодом, то пиши вот так:

...
if (x < 0) { this.doSomething(); throw error ("Error"); } // GLIBS: Some modification --
if (x == 0) return true;
...

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


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

Ок. Перехожу в режим чтения этой ветки.

[glibs]

Цитата:

Сообщение от mazzy

...
я же написал "только в простейших случаях, когда в каждой ветке делается return.".
...

А я писал, что любой изначально задуманный как простейший код может со временем усложниться.

Цитата:

Сообщение от mazzy

...
я же написал
...
Если вставляется оператор до return'а, а программист не проконтролировал скобки, то... это скорее говорит о неопытности программиста, нежели о Best Practice.
...

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

Например, ERP системы внедряют для снижения человеческого фактора и зависимости от личностей... я склонен к чему-то подобному в кодировании.

Цитата:

Сообщение от mazzy

...
Перехожу в режим чтения этой ветки.
...

У меня экономическое образование. Так что программирование воспринимаю как умею. Тоже с удовольствием послушаю более опытных коллег, если откликнутся.

[mazzy]

Цитата:

Сообщение от glibs

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

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

Цитата:

Сообщение от glibs

А я писал, что любой изначально задуманный как простейший код может со временем усложниться.

ну, дык. Усложни код, когда он усложнится. Заранее то зачем?

[mazzy]

согласен.

[belugin]

я бы скобок не ставил, а переносы бы делал.

[glibs]

Если писать Аксапту почти "с нуля", то не принципиально. Согласен.

[mazzy]

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

[glibs]

Цитата:

Сообщение от mazzy

...
ну, вот снова ловко изменил тему
...

К тому, как ты любишь уводить в сторону темы разговора, особенно когда они для тебя неприятны, очень хорошо подходит пословица: "Чья б корова мычала, а твоя бы молчала". Мне до твоего уровня мастерства в этом деле еще расти и расти.

Я вовсе не менял тему, а лишь просил всех участников обратить внимание на тот нюанс, что код в Аксапте не всегда является статическим. И то, что я сейчас напишу красиво и понятно, может начать смотреться очень уродливо после того, как кому-то потребуется доработать мой код. Т.е. я предлагал взглянуть на проблему не в статике, а в динамике. Тема та же. Читабельность кода.