[жж][башорк] Говнокод

> 2. Код должен быть прозрачным.

А что значит прозрачный? Писать в ворде и выставить цвет -> прозрачный?

>> 2. Код должен быть прозрачным.

> А что значит прозрачный? Писать в ворде и выставить цвет -> прозрачный?

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

возьмем тот же кусок:

a = b
b = c
c = a

Что он делает, конечно, понятно. Но вот когда он сдохнет? Как тут правильно заметили (кажется, клалафуда) сущесствует верояятность переполнения. На нее часто забивают и почти так же часто оно происходит.

Поэтому (согласно той же венгерской конвенции) полезно, чтобы
переменные несли информацию о своем типе (например, так):

a_int8 = b_int2
b_int2 = c_int8
c_int8 = a_int8

Тут сразц видно где слабое место. А в "языках" типа ПХП без этого
правила по понятным причинам вообще плохо.

>> a = b
>> b = c
>> c = a
>> Как тут правильно заметили (кажется, клалафуда) сущесствует верояятность переполнения. На нее часто забивают и почти так же часто оно происходит.

Здесь наоборот возможность переполнения "втихую" отсутствует. Нормальный компилятор при несовместимости типов выдаст предупреждение, которое нормальный программист не проигнорирует =).

Клалафуда говорил про вот этот код:

a = a + b
b = a - b
a = a - b

>> Поэтому (согласно той же венгерской конвенции) полезно, чтобы переменные несли информацию о своем типе (например, так):
>> a_int8 = b_int2
>> b_int2 = c_int8
>> c_int8 = a_int8

В данном случае венгерская нотация бесполезна (а она вообще когда-нибудь бывает полезна? не ради троллинга, самому интересно). Название переменной "a_int8" не гарантирует, что там на самом деле int64_t a_int8, а не что-то совершенно левое.

> Здесь наоборот возможность переполнения "втихую" отсутствует.
Нормальный компилятор при несовместимости типов выдаст предупреждение,
которое нормальный программист не проигнорирует =).

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

a_int8 = a_int8 + b_int2
b_int2 = a_int8 - b_int2
a_int8 = a_int8 - b_int2

Сделает этот кусок кода существенно более прозрачным. И выявит скрытые
проблемы переполнения.

>В данном случае венгерская нотация бесполезна (а она вообще
когда-нибудь бывает полезна? не ради троллинга, самому интересно).
Название переменной "a_int8" не гарантирует, что там на самом деле
int64_t a_int8, а не что-то совершенно левое.

Гм. Вообще то нотация содержит довольно много полезных правил, если
сделовать которым, то жизнь программиста (особенно при совместных
работах) сильно упрощается. Разумеется, если везде нотации следовали,
а в случаи a_int8 это на самом деле char, то тут нотация создаст
дополнительные трудности, НО по тупости программиста.

> Что он делает, конечно, понятно. Но вот когда он сдохнет?

если a, b и c одного [простого] типа, то, скорее всего, никогда не сдохнет.

> Как тут правильно заметили (кажется, клалафуда) сущесствует верояятность переполнения. На нее часто забивают и почти так же часто оно происходит.

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

> Поэтому (согласно той же венгерской конвенции) полезно, чтобы
переменные несли информацию о своем типе (например, так):

a_int8 = b_int2
b_int2 = c_int8
c_int8 = a_int8

боже упаси вас от ТАКОГО! даже в страшном сне.

// wbr

> a_int8 = b_int2
> b_int2 = c_int8
> c_int8 = a_int8

> Тут сразц видно где слабое место. А в "языках" типа ПХП без этого
правила по понятным причинам вообще плохо.

Открою секрет - в PHP нет int8 ;) Покрайней мере, мне один раз приходилось обрабатывать в PHP целые числа оставляя их в строке, ибо значения были чуть больше 32-бит. В документации есть примеры наколенных коленок по обработке таких "чисел".

Вообщем - ЖО.

> Вообще то нотация содержит довольно много полезных правил, если сделовать которым, то жизнь программиста (особенно при совместных работах) сильно упрощается.

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

наколенных коленок -> наколенных поделок

> a ^= b ^= a ^= b;

это некорректный код, годится только как мнемоническое правило

правильно так: b ^= a ^= b; a ^= b;

> Лучше посоветуйте, как имена переменных придумывать. На это больше всего времени уходит. Может я не знаю каких секретов?

Есть такое наблюдение: если имя не придумывается. значит нет ясности в смысле этой переменной.

> Открою секрет - в PHP нет int8 ;) Покрайней мере, мне один раз приходилось обрабатывать в PHP целые числа оставляя их в строке, ибо значения были чуть больше 32-бит. В документации есть примеры наколенных коленок по обработке таких "чисел".

В пхп вообще объявлять переменные не принято, от этого много бед.

>> наиболее типичная проблема - LOCK TABLE там не сделан, и это значит что полученное значение может другой клиент занять.

> И это логично делать в функции нахождения максимального элемента, а не в функции собственно вставки? Нет, я серьезно.

да, в предположении что снаружи поставят локи и тд - c этим кодом все ок.

Но опыт заставляет предположить обратное. Пару лет назад кто-то с мейл.ру публиковал "бенчмарк" PostgreSQL vs MySQL. дык он там не только таким образом реализовал sequence (без локов разумеется), но еще и по этой колонке индекса не имел, то есть для взятия следующего значения просматривал всю таблицу...

но это не тот код, у него на perl'е было.

> боже упаси вас от ТАКОГО! даже в страшном сне.

Это на смомо деле удобно и сильно облегчает жизнь:

Все переменные указатели начинаются на "p", объекты с большой буквы и т.д.: pRotor, pCar,....

в шаблонах аналогично:

typedef std::map< std::string, int > TmapSI;

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

> Это на смомо деле удобно и сильно облегчает жизнь:

Пристрелите его кто-нибудь, пока он ничего накодить не успел, а?

--*--

Отвлекаясь от грустных мыслей:

void main(argc,argv)
int argc;
char **argv;
{
  if (argc < 42) _exit(100);

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

>А что здесь не так? Неужели автор не знает, что не везде существует автоинкремент?

Не так тут хотя бы то, что при одновременном исполнении двух таких процессов получится полная херня.

>Чой-то я не понял, а что им в этом не понравилось?

Наверное, тем, что в питоне это делается в одну строчку: a, b = b, a

> PERL (0)

маловато будет.. запостите туда кто-нибудь LISP (666)

Ох, люблю же я вылезших из анабиоза...

Оказывается пыхпых тоже могуч, он гоняет стаю куч^W туч:

list($a, $b) = array($b, $a);

php -r '$a = 1; $b =2; list($a, $b) = array($b, $a); echo "a = $a, b = $b";'

> a ^= b ^= a ^= b;
> На С работает

Вообще то согласно стандарта это UB.

> Наверное, тем, что в питоне это делается в одну строчку: a, b = b, a

Это новичок, вероятно. Ндя, недавно глядел первые версии своей писанины на Питоне, времён его освоения, ржал дико. Жаль, всё потёр. А вот второй пример (#23) реально по накурке сделан.

>>a ^= b ^= a ^= b;
>>На С работает

undefined behaviour

я вчера вайпнул линуксом и башорком, капчу запилили.

>a ^= b ^= a ^= b;

Я уж было надеялся, что никто не вспомнит.... =\

Это мало того, что ещё менее читабельно, плюс нарушает стандарт.

я те сука яйца поотрываю, если еще раз такое повторится!

> >a ^= b ^= a ^= b;
> Я уж было надеялся, что никто не вспомнит.... =\
> Это мало того, что ещё менее читабельно, плюс нарушает стандарт.

Стандарт нерушим ;)
По стандарту это UB.

Это и имел в виду, неудачно выразился.

O, правда?