Индусские программисты и индусский код

[Dweller]

ЗЫ. ассоциативно подумалось. а если бы он написал !((!A)||(!B)) и на вопрос а почему не A&&B ответил "а мне так больше нравится, с детства не люблю конъюнкцию" - какова была бы реакция?

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

[Мальчик-Одуванчик]

только сегодня один phD на интервью мне написал
if (A) {
return A && B;
}
else ...

многопоточностью там и не пахло...

Чувак случаем не азиат?

[Dweller]

только сегодня один phD на интервью мне написал
if (A) {
return A && B;
}
else ...

многопоточностью там и не пахло...

Чувак случаем не азиат?

из Макао

[АццкоМото]

Есть люди которые любят напортачить только чтобы потом разгребать
Они нам не нужны

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

[Мальчик-Одуванчик]

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

Скорей всего заготовка с целью заменить потом true на реальное условие. Более экзотическое абиснение - не портить метрики: если считается, сколько кода добавлено, сколько изменено, а сколько удалено, могут не хотеть комментить временно неработающий код - по разным причинам

Так и не вспомнил тот конкретный вариант кода. Но вот какие мысли возникли.
if (false) {
..... проверка предусловий на уровне компилятора
} else {
... собственно код
}
предусловиями могут быть, к примеру, ограничения что какие то типы должны наследовать друг от друга, принадлежать определенной категории и тд
далее, после успешной проверки, весь проверочный код откидывается компилятором

[Мальчик-Одуванчик]

только сегодня один phD на интервью мне написал
if (A) {
return A && B;
}
else ...

многопоточностью там и не пахло...

Чувак случаем не азиат?

из Макао

Тогда и расчитывать на что-либо иное особо не стоит.
Зато вот пример классического российского говнокода
1. Изначальный вариант
if(A) { ... } и где-то далее имеем !A , где А - составное логическое выражение.
2. Российский программист обязательно постарается вывести !А в более простое выражение если это возможно. Результатом такого рукосуйства будет уже
if(A) { ... } и где-то далее имеем В, где В = !А но выглядит уже по-другому.

Впоследствии после изменения А уже никто не догадается одновременно изменить !А, поскольку просто не увидит такого условия в коде.

[Интеррапт]

люди, какой контекст вам нужен, чтобы конструкция "true && B" обрела смысл????

Там ведь нет "true && B" было, правда? _На интервью_ я бы к такому не придирался. В крайнем случае спросил бы чему это равно.

+1, нечего такого страшного в коде совершенно нет, т.к. это не ошибка, просто читается сложнее, чем если просто написать:
return B != 0;

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

[АццкоМото]

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

Скорей всего заготовка с целью заменить потом true на реальное условие. Более экзотическое абиснение - не портить метрики: если считается, сколько кода добавлено, сколько изменено, а сколько удалено, могут не хотеть комментить временно неработающий код - по разным причинам

Так и не вспомнил тот конкретный вариант кода. Но вот какие мысли возникли.
if (false) {
..... проверка предусловий на уровне компилятора
} else {
... собственно код
}
предусловиями могут быть, к примеру, ограничения что какие то типы должны наследовать друг от друга, принадлежать определенной категории и тд
далее, после успешной проверки, весь проверочный код откидывается компилятором

ммм
а какие условия на уровне компилятора можно реально проверить именно в исполняемом коде? (если речь про С/С++) как минимум
т.е. код кагбэ вроде не подразумевается исполняемым, но... хотелось бы пример

Хороший пример есть в линух кернеле (аффтар - линус)
28 #if _FP_W_TYPE_SIZE < 32
29 #error "Here's a nickel kid. Go buy yourself a real computer."
30 #endif
Пруф: http://git.kernel.org/?p=linux/kernel/g ... 3ca710e65f

Но это же не тот вариант, что вставляют в if(0). Да и проверка не компилятором, а препроцессором. Да и вообще... else по определению не нужен, а речь шла про if(1)

Не, я допускаю, что я что-то не догоняю, но... но...

[АццкоМото]

+1, нечего такого страшного в коде совершенно нет, т.к. это не ошибка, просто читается сложнее, чем если просто написать:
return B != 0;

А просто return B; - не кошерно?

Нет, конечно, как я уже пейсал - если все остальное ОК, то с этой ситуации нужно просто снять лулзов и не париться

[Интеррапт]

+1, нечего такого страшного в коде совершенно нет, т.к. это не ошибка, просто читается сложнее, чем если просто написать:
return B != 0;

А просто return B; - не кошерно?

Не, не нравится мне просто "return B". Если метод что-то вроде

int verify(int A, int B) {
if (A) return B;
...
}

а судя по изначальной комбинации A&&B - метод скорее всего должен возвращать ДА/НЕТ, то я предпочел бы, чтобы метод возвращал 1 или 0, а не какое-нибудь 35 в случае вызова verify(10, 35).

[АццкоМото]

Зато вот пример классического российского говнокода
1. Изначальный вариант
if(A) { ... } и где-то далее имеем !A , где А - составное логическое выражение.
2. Российский программист обязательно постарается вывести !А в более простое выражение если это возможно. Результатом такого рукосуйства будет уже
if(A) { ... } и где-то далее имеем В, где В = !А но выглядит уже по-другому.

Впоследствии после изменения А уже никто не догадается одновременно изменить !А, поскольку просто не увидит такого условия в коде.

Вот ни разу не видел такого. Многократное if (A) и if (!A), где А - довольно дорогое выражение - видел. А как вы приводите пример - ни разу

Еще меня задолбало видеть
if (A) {
object.metod().anotherMethod().property.yetAnotherMethod(3);
} else {
object.metod().anotherMethod().property.yetAnotherMethod(7);
}

чо, трудно напейсать
object.metod().anotherMethod().property.yetAnotherMethod(A?3:7);
????

Причем тут еще как-то очевидно, но у людей же так моск выворачивает, что не сразу поймешь

[Flash-04]

а это борьба с минимализмом "С"

[Alexander Troyansky]

Иногда использую:

Code: Select all

    if True:
          #дальнейший говнокод на Питоне

как временную меру. Кто с Питоном дело имел, наверное, поймёт почему.

[АццкоМото]

Не, не нравится мне просто "return B". Если метод что-то вроде

int result(int A, int B) {
if (A)
return B;
...
}

а судя по изначальной комбинации A&&B - метод скорее всего должен возвращать ДА/НЕТ, то я предпочел бы, чтобы метод возвращал 1 или 0, а не какое-нибудь 35 в случае вызова result(10, 35).

А смысл? Все равно int который по сути bool могут сравнивать только с нулем, но никак не с единицей. Более того, не знаю, как сейчас дело обстоит в стандартах, но когда деревья были большими A!=B совсем не было обязано равняться 0 или 1. Чуть чаще, чем всегда, это было эквивалентом (A-B)

Т.е. 35!=0 все равно равнялось 35

[Интеррапт]

А смысл? Все равно int который по сути bool могут сравнивать только с нулем, но никак не с единицей. Более того, не знаю, как сейчас дело обстоит в стандартах, но когда деревья были большими A!=B совсем не было обязано равняться 0 или 1. Чуть чаще, чем всегда, это было эквивалентом (A-B)

Т.е. 35!=0 все равно равнялось 35

Для красоты. Например, когда у нас есть в Си:

typedef int bool;

и мы пользуемся этим самым bool то во время отладки или распечатки хочется видеть именно 1 и 0, а не 35 и 0. К тому же возвращая return B != 0 как бы явно указываешь, что возвращаешь не значение B, а именно true/false.
Мало того, если речь про Java, то мы вообще не можем вернуть
boolean verify(..., int B)
{
...
if (...) return B;
...
}

будет ошибка компиляции. Обязательно должно быть return B != 0;

[АццкоМото]

Для красоты. Например, когда у нас есть в Си:

typedef int bool;

и мы пользуемся этим самым bool то во время отладки или распечатки хочется видеть именно 1 и 0, а не 35 и 0. К тому же возвращая return B != 0 как бы явно указываешь, что возвращаешь не значение B, а именно true/false.

Не, именно в С никакой гарантии получить 1 в качестве true нет (или, как минимум, не было раньше).
А судить о том, что возвращается, нужно по сигнатуре функции, а не по виду return, верно же?

Мало того, если речь про Java, то мы вообще не можем вернуть
...
будет ошибка компиляции. Обязательно должно быть return B != 0;

Муаххахха!!! Буквально 5 минут назад я думал так же. Однако вот этот код:

Code: Select all

    boolean x () {
    	int f = 5;
    	return f;
    }

Не вызвал у джавы никаких претензий. Чюдисатые чюдиса.

[Мальчик-Одуванчик]

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

Скорей всего заготовка с целью заменить потом true на реальное условие. Более экзотическое абиснение - не портить метрики: если считается, сколько кода добавлено, сколько изменено, а сколько удалено, могут не хотеть комментить временно неработающий код - по разным причинам

Так и не вспомнил тот конкретный вариант кода. Но вот какие мысли возникли.
if (false) {
..... проверка предусловий на уровне компилятора
} else {
... собственно код
}
предусловиями могут быть, к примеру, ограничения что какие то типы должны наследовать друг от друга, принадлежать определенной категории и тд
далее, после успешной проверки, весь проверочный код откидывается компилятором

ммм
а какие условия на уровне компилятора можно реально проверить именно в исполняемом коде? (если речь про С/С++) как минимум
т.е. код кагбэ вроде не подразумевается исполняемым, но... хотелось бы пример

D *pd; B* pb; pb=pd; - проверка что В базовый тип для D или они одного и того же типа

[Alexander Troyansky]

Для красоты. Например, когда у нас есть в Си:

typedef int bool;

и мы пользуемся этим самым bool то во время отладки или распечатки хочется видеть именно 1 и 0, а не 35 и 0. К тому же возвращая return B != 0 как бы явно указываешь, что возвращаешь не значение B, а именно true/false.

Не, именно в С никакой гарантии получить 1 в качестве true нет (или, как минимум, не было раньше).
А судить о том, что возвращается, нужно по сигнатуре функции, а не по виду return, верно же?

Мало того, если речь про Java, то мы вообще не можем вернуть
...
будет ошибка компиляции. Обязательно должно быть return B != 0;

Муаххахха!!! Буквально 5 минут назад я думал так же. Однако вот этот код:

Code: Select all

    boolean x () {
    	int f = 5;
    	return f;
    }

Не вызвал у джавы никаких претензий. Чюдисатые чюдиса.

А у меня так:

Code: Select all

class C
{
	static boolean x ()
	{
		int f = 5;
       		return f;
	}

	static void main(String [] args)
	{
		System.out.println(x());
	}
}

Code: Select all

C:\>C:\jdk1.6.0_33_x64\bin\javac.exe C.java
C.java:6: incompatible types
found   : int
required: boolean
                return f;
                       ^
1 error

[Интеррапт]

Мало того, если речь про Java, то мы вообще не можем вернуть
...
будет ошибка компиляции. Обязательно должно быть return B != 0;

Муаххахха!!! Буквально 5 минут назад я думал так же. Однако вот этот код:

Code: Select all

    boolean x () {
    	int f = 5;
    	return f;
    }

Не вызвал у джавы никаких претензий. Чюдисатые чюдиса.

Быть такого просто не может.

[Мальчик-Одуванчик]

Зато вот пример классического российского говнокода
1. Изначальный вариант
if(A) { ... } и где-то далее имеем !A , где А - составное логическое выражение.
2. Российский программист обязательно постарается вывести !А в более простое выражение если это возможно. Результатом такого рукосуйства будет уже
if(A) { ... } и где-то далее имеем В, где В = !А но выглядит уже по-другому.

Впоследствии после изменения А уже никто не догадается одновременно изменить !А, поскольку просто не увидит такого условия в коде.

Вот ни разу не видел такого. Многократное if (A) и if (!A), где А - довольно дорогое выражение - видел. А как вы приводите пример - ни разу

а мне сплошь и рядом попадались примеры, когда коньюнкция заменялась дизьюнкцией

[Dweller]

ну что, у нас первый отборочный раунд прошел (но возможно будет и второй), так что:
изначально задача стояла нарисовать decision tree that implements (A or not B) and (B or C)
ну и собсно в процессе чтобы подтолкнуть кандидата к решению я попросил написать код
т.е. хотелось увидеть:
if (B) {
if (A)
return True;
else
return False;
}
else {
...

[Интеррапт]

Не, именно в С никакой гарантии получить 1 в качестве true нет (или, как минимум, не было раньше).
А судить о том, что возвращается, нужно по сигнатуре функции, а не по виду return, верно же?

C99 стандартизировал, что true = 1, false = 0

[АццкоМото]

ну что, у нас первый отборочный раунд прошел (но возможно будет и второй), так что:
изначально задача стояла нарисовать decision tree that implements (A or not B) and (B or C)
ну и собсно в процессе чтобы подтолкнуть кандидата к решению я попросил написать код
т.е. хотелось увидеть:
if (B) {
if (A)
return True;
else
return False;
}
else {
...

Я туплю или код неверный?
UPD. Да, туплю.

[АццкоМото]

Не, именно в С никакой гарантии получить 1 в качестве true нет (или, как минимум, не было раньше).
А судить о том, что возвращается, нужно по сигнатуре функции, а не по виду return, верно же?

C99 стандартизировал, что true = 1, false = 0

Ой, вот все эти новомодные веяния

[8K]

Dweller, вы хотите странного. В общем случае, A нельзя переставлять местами с B.