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

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

Вставка точки с запятой в JavaScript.

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

Вот правила (из ECMA-262, раздел 7.9)

1. Если программа содержит токен, который не разрешен формальной грамматикой, то точка с запятой вставляется, если (а) в этой точке есть разрыв строки, или (b) неожиданный токен был закрывающей скобкой.
2. Когда достигнут конец файла, если программа не может быть проанализирована иначе, вставляется точка с запятой.
3. Когда встречается «ограниченная продукция» и содержит терминатор строки в месте, где грамматика содержит аннотацию «[здесь нет LineTerminator]», то вставляется точка с запятой.

Пример:

return 1; // returns 1

return
1; // returns undefined

Синтаксис Java-бина из-за отсутствия свойств C #

/**
 * Name of user
 */
private String name;

/**
 * Gets name of user
 * @return Name of user
 */
public String getName() {
    return this.name;
}

/**
 * Sets name of user. 
 * @param name
 */
public void setName(final String name) {
    this.name = name;
}

GAH !!!

Проблемы у меня с этим

• Слишком много кода. Иметь задокументированное поле, задокументированный метод получения и задокументированный метод установки. Этот чрезвычайно простой пример имеет 20 строк кода для одного свойства
• Загромождает списки метода - «Позволь мне найти этот метод, руку на: getX, getY, getZ, getAnotherAnnoyingField, getWhyIHateJavaBeans, getThisIsVerbose, getGAH... ах там, hashCode.
• Многочисленные области документации приводят к плохой, устаревшей или отсутствующей документации - раздражает при попытке понять, что делает код
• Так что надоедливой третьей стороне пришлось придумать плагин, чтобы сделать это легко - Spoon , Shark и другие.

Чувствительность к пробелам.

Python раздражает меня в этом отношении. Я имею в виду, я отступ правильно так или иначе, но это ошибка мне , что я должен иметь к. Создание представления частью синтаксиса раздражает меня.

switchЗаявление (в C, C ++, C #, Java и т.д.)

Вот пример того, почему я нахожу это очень неудобным:

switch (someVariable)
{
    case 1:
        int i = something();
        doSomething(i);
        break;

    case 2:
        int i = somethingElse();
        doSomethingElse(i);
        break;
}

Это не компилируется, потому что переменная iповторно объявлена ​​в той же области видимости. Это кажется незначительной деталью, но она часто кусает меня. Я могу добавить фигурные скобки, чтобы смягчить его, но было бы неплохо, если бы фигурные скобки были обязательной частью синтаксиса и не было избыточного дополнительного уровня отступа. Я также очень ненавижу писать дополнительные break. Это было бы намного лучше:

switch (someVariable)
case 1
{
    int i = something();
    doSomething(i);
}
case 2
{
    int i = somethingElse();
    doSomethingElse(i);
}
default
{
    ...
}

Это делает его более похожим на if/ elsechain, что хорошо, так как семантически похоже. По крайней мере, в C # это все равно не будет тем же, потому что в switchутверждении порядок меток регистра не имеет значения, но в if/ elseэто имеет значение.

Объявления массивов в VB.NET

Мне всегда удается забыть, что при инициализации фиксированных массивов в VB.NET вы указываете верхнюю границу массива, а не количество элементов, как в C / C ++, PHP или Java. Помимо VB6 (мы не пойдем туда ...), я не могу думать о другом языке, который делает это следующим образом:

Dim myArray(20) as Integer  '# Creates an array with 21 elements,
                            '# indexed from 0 to 20

VB6 - Отдельная декларация и присвоение переменной

Большинство языков позволяют вам объявлять переменную и назначать ее в одной строке кода; VB6, с другой стороны, заставляет вас использовать два.

Dim i as Integer
i = 0

Dim derpderp as Collection
Set derpderp = new Collection

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

Dim i as Integer: i = 0
Dim derpderp as Collection: Set derpderp = new Collection

Комментирование в CSS

//не закомментирует строки кода, как во многих других языках, таких как PHP и Javascript. Хотя /* this is commented out */работает, я предпочитаю использовать //.

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

PHP - последовательный порядок аргументов

В PHP есть несколько удобных функций для выполнения практически всех операций, которые вы можете себе представить над массивом или строкой. Многие из этих операций требуют использования и a, $needleи a $haystack, но разные функции принимают их в разных порядках. Какая функция требует, какие аргументы - один из тех фактов, которые мой мозг отказывается воспринимать, как бы часто я с ними ни сталкивался!

Возьмите функции in_array и strstr :

// Check whether $needle occurs in array $haystack
bool in_array (mixed $needle, array $haystack [, bool $strict])

// Check whether $needle is a substring of $haystack
string strstr (string $haystack, mixed $needle [, bool $before_needle=false])

Как ни странно, PHP кажется внутренне совместимым с этими порядками в том $haystack, $needleсмысле, что все строковые функции, кажется, используют, в то время как функции массива работают наоборот, но это может занять некоторое время, чтобы привыкнуть к кому-то новичку в PHP. В ExpressionEngine есть хороший пост, в котором более подробно рассказывается об этой специфической причуде, а также обсуждается список ошибок PHP , который содержит очень короткий ответ от команды PHP!

helly@php.net Тогда
используйте достойную IDE.

питон

self параметр в определениях метода экземпляра

Джава

Период. Полная остановка. Конец истории.

Когда начать? О, я знаю, с чего начать: Java - безумно сложный, уродливый, глупый и по своей сути сломанный дженерик. Нужно ли мне сказать больше? :( Хорошо, хорошо, тогда: erasure .

Тогда есть недетерминированное управление ресурсами. Kewl Footcher!

Что дальше? Ах да: глупые регулярные выражения Java - моя самая раздражающая, кипящая говядина. Я не могу сосчитать, сколько раз меня держали в руке из-за недостатка обратной косой черты. Это даже хуже, чем отсутствие доступа к каким-либо свойствам Юникода в этом тысячелетии, что вполне закономерно. Десять офигенных лет устарели !!! Совершенно бесполезно. Мусор это.

Тогда есть ошибка, что ярлыки класса персонажа не работают на не-ASCII. Какая королевская боль! И даже не подумайте об использовании \p{javaWhiteSpace}; он не работает правильно с несколькими очень распространенными точками пробела Unicode.

Знаете ли вы, что есть \p{javaJavaIdentifierStart}недвижимость? Что они думают? Я так рада, что они получили таких умных пиперов, как на жестком диске.

Вы когда-нибудь пытались использовать флаг CANON_EQ? Вы знаете, что на самом деле делает, а что нет ? Как насчет так называемого «случая Unicode»? Куча нормальных оболочек просто не работает.

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

    "(?= ^ [A-Z] [A-Za-z0-9\\-] + $)      \n"
  + "(?! ^ .*                             \n"
  + "    (?: ^     \\d+      $            \n"
  + "      | ^ [A-Z] - [A-Z] $            \n"
  + "      | Invitrogen                   \n"
  + "      | Clontech                     \n"
  + "      | L-L-X-X                      \n"
  + "      | Sarstedt                     \n"
  + "      | Roche                        \n"
  + "      | Beckman                      \n"
  + "      | Bayer                        \n"
  + "    )      # end alternatives        \n"
  + ")          # end negated lookahead   \n" 

Каковы все эти новые строки? О, просто глупость Java. Они использовали комментарии Perl, а не комментарии Java ( идиоты! ), Которые идут до конца строки. Так что, если вы не положите их \nтуда, вы отрубите остальную часть вашего паттерна. Дух и двойной дух!

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

Тогда мы можем начать говорить об идиотской бессмыслице Java с кодировками. Во-первых, существует тот факт, что кодировка платформы по умолчанию всегда представляет собой неаккуратную 8-битную кодировку, даже несмотря на то, что в Java используются символы Unicode. Тогда есть то, как они не вызывают исключение при ошибке кодирования. Вы гарантированно получите дерьмо. Или как насчет этого:

OutputStreamWriter(OutputStream out) 
          Creates an OutputStreamWriter that uses the default character encoding.
OutputStreamWriter(OutputStream out, Charset cs) 
          Creates an OutputStreamWriter that uses the given charset.
OutputStreamWriter(OutputStream out, CharsetEncoder enc) 
          Creates an OutputStreamWriter that uses the given charset encoder.
OutputStreamWriter(OutputStream out, String charsetName) 
          Creates an OutputStreamWriter that uses the named charset.

Какая разница? Знаете ли вы, что только один из них вызовет исключение, если у вас есть ошибка кодирования? Остальные просто намордники.

Тогда есть идиотизм символов Java, не достаточный, чтобы держать характер! Что, черт возьми, они думают? Вот почему я называю их чарчарами. Вы должны написать такой код, если ожидаете, что он будет работать правильно:

private static void say_physical(String s) { 
    System.out.print("U+");
    for (int i = 0; i < s.length(); i++) {
        System.out.printf("%X", s.codePointAt(i));
        if (s.codePointAt(i) > Character.MAX_VALUE) { i++; }  // UG!
        if (i+1 < s.length()) { System.out.printf("."); }
    }
}

А кто нибудь думает это сделать? Рядом ни с кем.

Сколько персонажей там "\uD83D\uDCA9"? Один или два? Зависит от того, как вы их считаете. Механизм регулярных выражений, конечно, работает с логическими символами, поэтому шаблон ^.$будет успешным, а шаблон ^..$- неудачным. Это безумие демонстрируется здесь:

String { U+61, "\u0061", "a" }  =~ /^.$/ => matched.
String { U+61, "\u0061", "a" }  =~ /^..$/ => failed.
String { U+61.61, "\u0061\u0061", "aa" }  =~ /^.$/ => failed.
String { U+61.61, "\u0061\u0061", "aa" }  =~ /^..$/ => matched.
String { U+DF, "\u00DF", "ß" }  =~ /^.$/ => matched.
String { U+DF, "\u00DF", "ß" }  =~ /^..$/ => failed.
String { U+DF.DF, "\u00DF\u00DF", "ßß" }  =~ /^.$/ => failed.
String { U+DF.DF, "\u00DF\u00DF", "ßß" }  =~ /^..$/ => matched.
String { U+3C3, "\u03C3", "σ" }  =~ /^.$/ => matched.
String { U+3C3, "\u03C3", "σ" }  =~ /^..$/ => failed.
String { U+3C3.3C3, "\u03C3\u03C3", "σσ" }  =~ /^.$/ => failed.
String { U+3C3.3C3, "\u03C3\u03C3", "σσ" }  =~ /^..$/ => matched.
String { U+1F4A9, "\uD83D\uDCA9", "💩" }  =~ /^.$/ => matched.
String { U+1F4A9, "\uD83D\uDCA9", "💩" }  =~ /^..$/ => failed.
String { U+1F4A9.1F4A9, "\uD83D\uDCA9\uD83D\uDCA9", "💩💩" }  =~ /^.$/ => failed.
String { U+1F4A9.1F4A9, "\uD83D\uDCA9\uD83D\uDCA9", "💩💩" }  =~ /^..$/ => matched.

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

Stoooopid.

Пока мы в этом, вся \uXXXXнотация врожденно умерла. Препроцессор Java ( да, вы слышали меня ) добирается до этого раньше, чем Java, поэтому вам запрещено писать совершенно разумные вещи, например "\u0022", потому что к тому времени, когда Java это видит, его препроцессор превратил его в """, и вы проиграете. Ой , подождите, не , если это в регулярном выражении! Таким образом, вы можете использовать "\\u0022"просто отлично.

Riiiiiiiight!

Знаете ли вы, что в Java нет способа сделать isatty(0)звонок? Тебе даже не позволено думать такие мысли. Это не будет хорошо для вас.

И затем есть вся мерзость пути класса.

Или тот факт, что невозможно указать кодировку исходного файла Java в том же исходном файле, чтобы вы не потеряли его? Я еще раз требую знать: ЧТО, ЧТО ОНИ МЫ ДУМАЛИ?

Останови безумие! Я не могу поверить, что люди терпят этот мусор. Это полная шутка. Я бы предпочел быть приветствующим Walmart, чем страдать от слингов и стрел возмутительного безумия на Яве. Это все сломано, и они не только не могут это исправить, но и не могут это исправить.

Это те же самые люди-лисички, которые гордились тем, что сделали незаконным printf()функционирование. Ну и дела, что действительно сработало очень хорошо, не так ли?

Чистые черепа. Шлепки слишком добры к ним. Если бы я хотел программировать на ассемблере, я бы. Это не подлежащий спасению язык. У императора нет одежды.

Мы ненавидим это. Мы ненавидим это навсегда . Пусть умирает, умирает, умирает !

Синтаксис объявления указателя функции в C и C ++:

(int)(*f)(int, int);

Это объявляет указатель на функцию с именем, fчье pointee может принимать два ints и возвращать int.

Я бы предпочел такой синтаксис:

f: (int, int) => int

Скажем, вы хотите объявить указатель на функцию, gчей pointee может взять два ints и функцию из intи intв int, и вернуть int.

С нотацией C или C ++ вы бы объявили ее как:

(int)(*g)(int, int, int(int, int));

С помощью предложенных выше обозначений то же самое может быть объявлено как:

g: (int, int, (int, int) => int) => int

Последнее гораздо более интуитивно понятное ИМО.

Кроме того: язык программирования под названием OOC исправляет этот синтаксис (и другие синтаксические проблемы в C и C ++). Проверьте его домашнюю страницу здесь .

Многословие в Java.

то есть:

public static final int 

\ we \ notnt \ fix \ синтаксис пространства имен нашего \ parser в PHP

Синтаксис не только уродлив, он приводит к путанице, когда новым разработчикам приходится задумываться о пространствах имен в строках. (PHP интерполирует обратные слэши в строках в двойных кавычках в качестве escape-последовательностей. Попытка представить пространство имен, как \you\should\never\do\thatв строке в двойных кавычках, а не в строке в одинарных кавычках, приведет к появлению новых строк, вкладок и к катастрофе.)

Я презираю тот факт, что фигурные скобки могут быть необязательными после оператора if / while / for.

Особенно, когда я вижу код, как,

if (...)
    for(...)
        ... One line of stuff ...

Пожалуйста, просто вставьте скобки и покончите с этим.

VBScript не имеет логических операторов

В отличие от почти каждого разумного языка, VBScript использует побитовые операторы вместо логических операторов. Что это значит на практике? Ну, как отмечает Эрик Липперт :

If Blah = True Then Print "True!" Else Print "False!"

а также

If Blah Then Print "True!" Else Print "False!"

НЕ одинаковы в VBScript!

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

If (Not Blah Is Nothing) And (Blah.Frob = 123) Then
...

Правильно, VBScript оценит обе части сравнения AND, даже если первая из них неверна! Просто позволь этому погрузиться ...

РЕДАКТИРОВАТЬ: После обсуждения в комментариях я решил обновить этот ответ, чтобы объяснить себя лучше.

Я действительно ненавижу то, как указатели на функции выглядят в C. Обычно любое объявление переменной выглядит как кортеж: type varname; Объявления указателя функции, с другой стороны, выглядят как объявление функции с * перед именем функции. Я могу принять это как описание типа указателя, но в Си это объявляет как тип, так и имя переменной этого типа. Это выглядит противоречивым для меня, потому что объявления типов иначе отличаются от объявлений переменных. struct myStruct{int X; int Y;}определяет только тип, но не определяет переменную с именем myStruct. Точно так же я не вижу причин для объединения объявлений типов и объявлений переменных в один атомарный оператор в указателях функций, а также я не ценю отклонение отtype varname; структуры.

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

Точки с запятой в VBScript - или их отсутствие

Я провожу весь день, работая на языках, которые ожидают точки с запятой в конце каждой строки. Добавьте один конец строки в VBScript, и ваш код больше не будет выполняться.

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

Здесь я нацеливаюсь на функции, которые берут входные данные из параметра, а затем перезаписывают этот вход некоторым выводом. Это нормально, чтобы передать объект по ссылке, чтобы обновить его. Но, в основном, для примитивных типов: взять объект, использовать его, а затем полностью его изменить, я не прав. Вы не должны менять значение аргумента через inout.

Объявления массивов в C и C ++.

Как правило, объявление переменной имеет формат type variable_name. Вы можете легко прочитать эти объявления слева направо. Но int foo[size]сначала выглядит так, будто оно объявляется fooкак int, а затем вы читаете дальше и видите, что foo типа «массив целых чисел». int[size] fooчитает намного лучше.

И я ненавижу, когда программисты объявлять указатели , как это по той же причине: int *foo. По какой-то причине я не понял, это типичный способ написания.

Резервная параметризация в Java:

HashMap<String,HashMap<String,String>> foo = new HashMap<String, HashMap<String, String>>();

Что другой типа параметризация делает компилятор думает foo , может иметь?

Поскольку люди уже жаловались на « =против» ==, позвольте мне указать на гораздо худшую альтернативу. У PL / I было и то :=и другое =, но когда что-то было «очевидно» заданием, это позволяло бы вам избежать использования =для этого. С помощью:= позволяет вам заставить что-то быть присваиванием в ситуации, когда компилятор иначе интерпретирует это как сравнение.

К сожалению, компилятор не всегда принимал решения так, как вы ожидаете. Рассмотрим только один очевидный пример:

A = B = 0;

Теперь, для большинства людей, знакомых с большинством "обычных" языков, смысл этого довольно очевиден - присваивать 0 как A, так и B. PL / I немного ... отличается. По причинам, известным только (безумным) разработчикам языка, первое =интерпретируется как задание, а второе= - как сравнение. Следовательно, это сравнивает B с 0, а затем присваивает результат этого сравнения A (в соответствии с соглашением в стиле C, что «false» приводит к 0 и «true» в 1).

Итак, если B было 0, то A становится 1. В противном случае A становится 0. Другими словами, вместо того, чтобы присваивать одно и то же значение A и B, это фактически гарантирует, что A не сможет иметь то же значение, что и B.

Итог: хотя изначально стиль C / C ++ / PHP кажется болезненным, альтернатива намного хуже ¹ .

¹ Технически, есть другая альтернатива: стиль Pascal, где =всегда означает, что всегда требуется сравнение и назначение :=. После того, как вы используете это в течение некоторого времени, становится достаточно очевидным (по крайней мере для меня), что назначение является более распространенным, чем сравнение, что, если вам потребуется дополнительная «вещь» для устранения неоднозначности, вы должны определенно сохранять задания чистыми и простыми, и требует дополнительных «гранж» при сравнении, а не наоборот.

Perl

1. Я хотел бы, чтобы Perl позволил мне написать if($x < 10) do_something();. На данный момент вы должны написать это либо как, либо do_something() if($x < 10);как if($x < 10) { do_something(); }.

reinterpret_cast<unsigned long>в с ++. Эта операция полезна при работе с зарубежными API и обеспечивает точность числовых данных. Почему печатать так трудно и так уродливо?

Конструкция for ... in в JavaScript и конструкция foreach в PHP при зацикливании массивов. Оба из них облегчают написание ошибок, чем правильный код.

Указатели массивов или массивов указателей в C / C ++. Я все еще смущен этим.

Тот факт, что Python опирается на форматирование текста.

Javascript / Java и т. Д., Равнозначное сравнение, например, если (a == 1)

Сколько раз я пишу, если (a = 1)?

Как человек, я прекрасно это прочитал. Но проклятый интерпретатор / компилятор говорит: «Эй, я назначу 1 для a, затем проверим, равно ли a 1, и вы поверите, да, это так!

Подводит меня к стене.

если (a == 1) гораздо менее читаемо, и интерпретатор / компилятор должен в любом случае знать, что я имею в виду; многие другие менее известные языки (VB) успешно работали в течение сотен лет.

Многословие в Java анонимных классов. Будем надеяться, скоро исправят.

structPointer->memberв C / C ++. Может быть хорошо читать чужой код, но мне это не нравится. Два персонажа вместо одного ... какая трата пространства!

Многострочный код Scala в скобках

Например:

class Foo(
         val bar: String,
         val baz: Int,
         val bing: String,
         val bong: Boolean
 ) extends Model {
   // body here
 }

То, что вы на самом деле получаете от этого, потрясающе. Он генерирует конструктор, геттеры и сеттеры для вас. Но это, конечно, уродливо и ломает все мои ментальные модели того, как делать отступы в коде, и в основном заставляет меня чувствовать, что я нахожусь в каком-то странном бутерброде с Java с одной стороны и Lisp с другой. (Ой, подождите ... это скорее точка Скала.)