Пользователь
0,0
рейтинг
25 июня 2010 в 14:21

Разработка → Жаргон программистов

Наткнулся на Stackoverflow.com на интересный топик с вопросом о новом в программистском жаргоне. Предлагаю здесь подборку наиболее интересных выражений.

Египетские операторные скобки

if (a == b) {<br>  printf("hello");<br>}<br><br>


Fear Driven Development


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

Hope Driven Development

Разработка, управляемая надеждой — разработка в длительном неспланированном цикле с надеждой, что все заработает в релизе

Rob Busack: Реальная модель водопада Waterfall Model.


Названо после ежегодного уикэнда быстрой разработки имени Rob Busack.

РеФАКторинг

реФАКторинг — получение полностью неподдерживаемого кода путем небольших изменений качественного и хорошо спроектированного кода.

Код — Пахлава


Многослойный многоуровневый код

Нажимай сильнее /Неправильный палец/ правильно держи мышку

Реакция разработчика на утверждения тестировщиков о том, что что-то не работает при использовании одного из устройств ввода.
Тестировщик: Модуль X не работает корректно
Разработчик: Покажите шаги тестирования
Тестировщик: Я коснулся его, затем… ой, подождите, сейчас все работает .
Разработчик: Каким пальцем вы касаетесь экрана?
Тестировщик: Указательный палец
Разработчик: Должно быть раньше вы использовали неправильный палец.
Тестировщик: Да… пожалуй..


Строковая типизация (Stringly typed vs strongly typed)

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


Естественный отбор

Замена чужого кода собственным.


frAGILE

frAGILE — выведение людей из себя путем неверного использования методологий Agile

Менеджер проекта: Давайте использовать методологии Agile!
Разработчик: Окей. Я буду делать минимум для достижения необходимой бизнес-функциональности.
Менеджер проекта: Отлично!
Разработчик: Мы сможем сделать рефакторинг после того, как будут построены другие части системы. Сейчас это не очень важно.
Менеджер проекта: Хорошо. Мы не должны делать больше, чем нужно
Позже в проекте…
Разработчик: Мы нуждаемся в рефакторинге, потому что код неподдерживаемый
… Затем…
Менеджер проекта: Выбор отговорки для отказа от развертывания:
  • Мы сможем сделать это немного позже
  • Если все работает, зачем что-то менять?
  • У нас нет времени на этот «рефакторинг»
  • Я обещаю, что мы сделаем это позже
В итоге: Разработчик страдает от увеличивающегося бессвязного кода-спагетти и никого это не заботит.
CTO: Agile это отвратительно! Никогда не будем использовать это! Модель водопада рулит!


Босс-билд

Создание специальной версии релиза продукта для запуска на компьютере «Босса». Например, Босс-билд может включать бесконечный список особых шрифтов, цветов, размеров и расположений элементов управления, меняющийся каждые несколько дней.

Интерфейс Джеймса Бонда


Контракт очень хорошо определен и документирован, но в реальности ничего не реализовано.

Класстрофобия

Отказ от объектно-ориентированного подхода при очевидной необходимости и возможности его использования.

Очень ориентированное программирование(ООП, Over Oriented Programming)

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


Паттерн документирования «Буказоид»(Bukazoid documentation pattern)

Все описание бесполезно и не отвечает ни на один из возникающих вопросов к коду. Вместо буказоидов можно использовать любое несуществующее слово, в русском языке, похоже, больше всего подходят бутявки.
/**<br> * Bukazoid manager is a manager to manage bukazoids.<br> */<br>public class BukazoidManager extends SomeOtherClass {<br>...<br>}<br><br>

Метод Перкова

The Perkov Method — стиль программирования, основанный на комментариях в виде псевдо-кода и допущении, что кто-то, кто будет делать обзоры кода реализует недостающую функциональность. В финальной стадии комментарии могут быть в 4 раза подробнее, чем это необходимо в реализации.Пример: обычная реализация Hello World:
class Program <br>{ <br>  static int Main(string[] args) <br>  {     <br>    Console.WriteLine("Hello World"); <br>  } <br>}<br><br>
Реализация по методу Перкова:
class Program <br>{ <br>  static int Main(string[] args) <br>  {  <br>    // at this point the program really should be outputting text to the <br>    // console. we must take into account 78 character maximum line length<br>    // and ensure that we use Environment.NewLine for line endings. <br>    // ideally should provide multi-region language support and UTF-8 / <br>    // UTF-16 encoding. <br>  } <br>}<br><br>


Маркетинговые байты

Байты, измеряемые как множители 1000


Корабль в бутылке


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

Методология разработки Пинг-Понг


Пусть пользователи будут тестировщиками, подайте им сырой продукт и примите порцию багов.

Дарвиновское программирование/Экспериментальное программирование

Изменение кода(как правило, случайное) без понимания смысла изменений, пока он не заработает. Например, замена инкремента на декремент.


TDDD: Technical Debt-Driven Development

(*исправлено хабраюзером dale )Разработка управляемая техническим долгом. То есть, когда разработчик постоянно откладывает фиксы и улучшения в коде «на потом».
Яхнев Александр @Yakhnev
карма
62,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (282)

  • +22
    >API упрощен до такой степени, что пользоваться им до отчаяния сложно.
    Беда многих известных сервисов.
    • –8
      А Вы сами пробовали реализовать api?
      • +11
        «Не надо ехать в Детроит, чтобы понять, как там воняет.» Доктор Хаус
        • +5
          1 — Я в таких случаях говорю понятнее «не надо быть гением в области математики, чтоб знать что 2х2=4»
          2 — Доктор ваш говорил не «как там воняет» а «как там плохо»
          (шутка основанная на том что слово «воняет» в английском языке на жаргоне означает «фигня»)
          • +4
            • –4
              Ага, и в этом холиваре египетские скобки побеждают ^___^ а ещё аниме рулит!!!
          • 0
            Но чтобы понимать более сложные вещи(типа парадокса Монти Холла), надо знать матчасть :)
            • +1
              Кто спорит то?

              Однако обязательно ли построить самому дом, перед тем как жаловаться на то что без лифта на 120-й этаж подниматься не удобно?

              Что проще, оценить сложность использования, или создание собственного API?
              • 0
                Даже пойдём дальше, может отменим тестирование софта?

                Люди занимающиеся тестированием ведь не имеют право указывать на ошибки, они же не программисты, от них не требовалось из кожи вон лезть чтоб реализовать фиг знает что, фиг знает какими путями, что они вообще могут знать о создании софта…

                Фидбэк вообще запретить законодательно…
  • +8
    Отличный пост! В некоторых местах посмеялся от душа.

    З.Ы. Египетские операторные скобочки ненавижу всей душой :)). Вспоминается комикс, где программист спрашивает у нового тимлида: «So, you are curly-bracket-on-the-same-line man or curly-bracket-on-the-next-line man»?
    • +5
      *от души
      • +65
        А я люблю египетские скобки и ненавижу те, которые на следующей линии=))
        • +12
          А, между прочим, «египетские скобки» — это кагбэ стандарт :)
          java.sun.com/docs/codeconv/
          • +24
            … в Java
            • 0
              Да, извините, не дописал
            • +3
            • –32
              учитывая распространенность Java — это и есть стандарт.
              • +5
                Т.е. все языки должны подчиняться стандарту Java?
                • –8
                  ни в коем случае. понятно, что для того Delphi или python это вообще не имеет значения, но для С-подобных языков актуально.

                  я сам не очень люблю Java, но я за то, чтобы код был чистым и понятным и чтобы стиль был какой-то, даже пускай это будет стиль согласно Java Code Convention.
                  • +5
                    было бы логичней говорить что для С-подобных языков более подходит С-подобный стандарт, а не давить на Java
                    • +3
                      Что вы, языки С/С++ как отдельная разновидность языка Джава, от которого они прошли, должны наследовать стандарты своего «родителя».

                      И вообще, учитывая, что джава используется почти везде, было бы негоже вспоминать про б-гом забытые языки.
                      • 0
                        Осторожнее… С подобным коментом, да без тега можно и по карме от холиварщиков получить)
                        • 0
                          Пардон… тега <irony>
              • +4
                Учитывая то, что это все же C-подобный синтаксис, я бы не стал делать таких заявлений.
          • 0
            Без проблем могу и так и эдак. С интересом наблюдаю со стороны за разборками между противниками и сторонниками.
            • 0
              Религиозные войны, как их правильно кто-то назвал.
          • 0
            Хорошие рассуждения на тему скобок есть в книшке «Совершенный код». Рекомендую.
        • 0
          Присоединяюсь. Вполне удобный стиль, и сам предпочитаю именно его.

          <irony>Да и не зря ведь он назван «One True Brace Style» =) </irony>
          • +1
            оба стиля удобны, просто каждый выбирает свои удобства
            • 0
              Абсолютно с вами согласен.
            • 0
              Оба стиля удобы по-своему.
              — Для стиля с переносом скобки на новую строку характена наглядность, т.к. явно выделены блоки, но при этом, увы, используется очень много вертикального пространства.
              — Для египетских скобок характерна чуть меньшая наглядность (наример, при 4-уровневых вложенностях if-for), зато места гораздо больше.

              Я лично строго придерживаюсь того стиля, который принят в команде программистов, где я работаю. А личное предпочтение отдаю стилю с переносом.
              P.S. Еще бы IDE выделяли блоки, а строки со скобками скрывали — и место бы экономилось, и наглядность повышалась.
              • 0
                4-х уровневые вложенности if-for еще принято заменять обьектной абстракцией ;)
        • +2
          Люблю языки где можно обойтись без скобок
          • НЛО прилетело и опубликовало эту надпись здесь
            • –1
              А я бы писал так:
              10 REM The 'Hello, world' program by Vladson
              20 PRINT "HELLO, WORLD"
              30 IF INKEY$="" THEN GOTO 20
              • 0
                Еще спросите «Какой сегодня день?… Год какой?»
        • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          И я люблю :)
    • +28
      А мне нравистя оставлять на той же строке.
      В этом случае я вижу оператор (if) и точно под ним завершающую скобку.
      Если скобка на следующей строке, то получается лишняя строка, которая не добавляет читаемости.
      • +2
        Именно так. Код получается более строгим и читаемым. В случае «неегипетских скобок» приходится использовать лишнюю табуляцию для индента — открывающаяся скобка отбивается одной табуляцией, код внутри операторных скобок соответственно двумя табуляциями. При вложенности операторных скобок количество табуляций по сравнению с «египетским» вариантом увеличивается вдвое. А если оставлять открывающуся скобку на уровне с предшествующим оператором — ухудшается наглядность.
        • 0
          Вы очень верно описали суть причины дискомфорта!
          • +2
            а разве сейчас кто-то пытается экономить «лишние» табуляции? код, который из-за табуляций еле влезает по ширине в экран нуждается в декомпозиции.
            • +6
              Дело не в табуляциях, а в том, что код содержит существенно больше строк и перестает влезать по высоте.
              Я сам не люблю очень плотный код, когда одна функция сидит на другой, поэтому между функциями оставляю две строки вместо одной. Взамен я имею четкое видение кода «с высоты птичьего полета», просто по плотности текста, где функция, где разрыв. Но в данном случае, идет разрыхление внутри функций — код получается более рыхлый, монотонный, глазом хуже выхватываются блоки.
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  Нет, не понравилось как он работает.
                • 0
                  фолдинг — он, конечно, позволяет спрятать то мясо, что кодер запихнул в функцию. И не видеть, что файл разросся. И класс. И…

                  Фу :)
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • +1
                      ну, написание больших запросов, хранимых процедур и прочего реляционного фуфла — тема для отдельного нытья и холивора на годы.

                      Мое скромное мнение сводится к следующей мысли: разработчики БД немножко увлеклись и позабыли, что задача баз — хранение данных, а не программирование.

                      Довольно противный декларативный язык — SQL, отвратительные диалекты PL/SQL, бла-бла-бла… Я отдельным матерным словом обычно поминаю отстойнейший sqlplus, для которого за одиннадцать версий базы разработчики не сподобились даже просто повторить функционал либы readline

                      Фолдинг, не фолдинг, подсветка не подсветка… Этим больным поможет только смерть. :)

                      Так о чем мы? Ах да. Так а нафиг вам фолдинг? что позволяет вам делать? ну свернули вы if, while или switch. И что? Появилось чувство, будто ваша функция стала аккуратней и короче?
                      • НЛО прилетело и опубликовало эту надпись здесь
                      • 0
                        Фолдинг для методов и вложенных классов — штука полезная.
                        А также для документирующих комментариев типа JavaDOC.
                  • 0
                    Лучше смотреть на номер последней строки файла ) помогает
        • НЛО прилетело и опубликовало эту надпись здесь
        • +37
          Эм, то есть Вы делаете вот так:
          if(a)
              {
                  foo();
              }
          

          ?
          Это не правильно, надо так:
          if(a)
          {
              foo();
          }
          

          • +7
            Поддерживаю
          • 0
            Кстати, а как вы делаете switch? Отхожу от стандарта, делая вот так:

            <код>
            switch( msg )
            {
            case WM_PAINT:
            pDc->Rect( 0, 0, 128, 128 );
            break;
            case WM_QUIT:

            }
            </код>
            • –2
              Пардон, табуляторы съело :(

              <код>
              switch( msg )
              {
              case WM_PAINT:
              pDc->Rect( 0, 0, 128, 128 );
              break;
              case WM_QUIT:

              }
              </код>
              • +2
                Они издеваются!

                switch( msg )
                {
                ____case WM_PAINT:
                ________pDc->Rect( 0, 0, 128, 128 );
                ________break;
                ____case WM_QUIT:
                ________…
                }
                • +1
                  Мне почему-то больше близка такая конструкция:
                  if(WM_PAINT == msg)
                  {
                      foo();
                  }
                  else if(WM_QUIT == msg)
                  {
                      bar();
                  }
                  ....
                  else
                  {
                      default();
                  }
                  


                  Наверно, если бы делал, то делал так:
                  switch(msg)
                  {
                      case WM_PAINT:
                          foo();
                      break;
                  
                      case WM_QUIT:
                      case 0:
                          bar();
                      break;
                  }
                  

                  Но выглядит все равно как-то уродско.
                  • +1
                    вы просто не умеете их готовить.

                    switch(msg)
                    {
                    	case WM_PAINT:
                    	{
                    		foo();
                    		break;
                    	}
                    	case WM_QUIT:
                    	case 0:
                    	{
                    		bar();
                    		break;
                    	}
                    }
                    
                    
                    • 0
                      А в case'ах зачем скобки?
                      • +2
                        Скобки нужны в случае обьявления переменных в одном из case'ов. В данном конктретном случае в них нет необходимости.
                      • 0
                        для наглядности.
                        Плюс в современных ide удобно выделять/скрывать/идентифицировать логические блоки с помощью скобок.
                    • –3
                      Да, так получается красивее. Но break совсем не к месту, ведь он не несет смысла в блоке выполняемых операций.
                      • 0
                        При отсутствии break'а, при выполнении случая WM_PAINT, выполняться и все последующие case'ы. В данном случае при msg == WM_PAINT вызвалось бы и foo(), и bar().
                        • 0
                          Я понимаю это, и это — отвратительная особенность case. break не связан со смыслом того, что должно выполняться, он связан со смыслом того, что не должно выполняться. Это можно переписать в более абсурдном виде:
                          foo();
                          do_not_execute_bar();
                          bar();
                    • 0
                      Эх, Си, Си…
                      Вот enum в Java позволяет сделать это полиморфизмом, в итоге надобность в switch практически отпадает.
                • 0
                  А мне ближе так (без лишнего отступа):
                  
                  switch( msg )
                  {
                  case WM_PAINT:
                      pDc->Rect( 0, 0, 128, 128 );
                      break;
                  case WM_QUIT:
                      …
                  }
                  
        • +10
          Да уж, наглядность значительно ухудшилась…

          if (true) {
              foo();
          }
          


          if (true)
          {
              foo();
          }
          
          • +3
            Да ладно, дело вкуса :) По моему, особой разницы нет.
            • +19
              Главное не использовать оба стиля сразу, за это — руки отрывать.
              • +4
                Опять же — зависит от стайл-гайда. Популярный code conventions для перла рекомендует обычные скобки для основных функций и «ебипетские» — для всего остального.

                sub foo($)
                {
                    my $callback = sub {
                        # do something...
                    };
                
                    if (...) {
                    }
                
                    # и так далее
                }
                
                • +4
                  Ядро линукса вроде тоже таким стилем пишут. Функции в BSD-стиле, управляющие конструкции — в египетском.
                  lxr.linux.no/#linux+v2.6.34/Documentation/CodingStyle
                • +1
                  +1 много где такой стандарт кодирования, например, в Zend Framework на похапе.
                • 0
                  А хороший стиль, надо перенять.
                • 0
                  Но не везде/не всегда. Как раз именно в перле выгодно фигурные скобки на отдельных строках использовать для обозначения многострочных блоков (вкупе с использованием завершающих точек с запятой в них для определённости), а египетские — для хэшрефов (поскольку последние тоже могут занимать большие пространства):

                  sub foo
                  {
                     return somefunc( {
                     number => 42,
                     string => 'asdf',
                     code =>
                        sub
                        {
                           #callback;
                        },
                     array => [ grep { defined; } @_ ],
                     });
                  }

                  Но в любом случае стиль кодирования на перле задать однозначно невозможно, т.к. существует тысячи областей его применения.
                  • 0
                    P.S. добавьте мысленно один уровень отступа между строками с number и array включительно
              • 0
                Вообще, современные IDE творят чудеса и могут привести весь код к заданному стилю одним нажатием хоткеев :)
                • 0
                  Опять же, это не про перл. Его даже perl-tidy не всегда берет…
                  • 0
                    Как раз про перл. perltidy если не берёт Ваш перл, это сигнал начать менять свой стиль или уволить своего программиста.
                    • 0
                      Это было что-то вроде шутки :)

                      Хотя не такой уж и шутки. Сейчас не могу найти, но один раз получился у меня со всех сторон валидный код (ну, по правде говоря, регэксп — но валидный!) на котором сломался хайлайтер Комоды и перл-тайди.

                      Как найду этого зверя — покажу.
                      • 0
                        В общем случае, выполнить разбор Perl-программы, не запуская её, невозможно. Поэтому вполне можно поверить на слово, что такие конструкции есть.
                • 0
                  Ваш комментарий был бы значительно полезнее если бы Вы сказали какой хоткей в какой IDE приведет код к одному стилю.
                  • 0
                    ctrl+alt+l в intellij idea
                • 0
                  Да, могут, но только в пределах своей компетенции. А, хотя они и довольно-таки мощные, некоторые отдельные фишки в некоторых IDE отсутствуют, причем в каждой — свои.

                  Например, в IntelliJ IDEA вроде бы все здорово, но иногда мне хочется форматировать не весь JavaDOC, а только пустые строки и @param, @return и т.д., при этом НЕ форматировать остальной текст. Увы, IDE этого не умеет, и приходится отрубать автоформатирование JavaDOC.
          • +7
            На мой взгляд, первый вариант существенно лучше, чем второй.
            Вот к чему там открывающая скобка? Ради чего ей выделена отдельная строка?
            В первом случае четко видно — вот он if, а вот закрывающая его }.
            Во втором я вижу { и }, но все равно мне нужно еще проверить к чему они относятся — то есть найти if.
            • +3
              А мне так удобнее, более чётко и однообразно видно структуру.

              Кроме того, не вижу смысла экономить строки, при длине метода в 10-20 строк.
            • 0
              Визуально видно блок условия, если использовать египетский стиль, условие сливается с кодом, нужно следить за табуляцией
              • 0
                Я запутался в вашем предложении.
                «Я дурак, если он дурак, ты дурак.» К чему относится средняя часть — та, что между запятыми? К первой части или к последней?
          • –2
            А на самом деле надо так:

            if (true) {
            foo();
            } // if (true)
            • 0
              Что уж там, давайте сразу
              if (true) {foo();}
              • 0
                А на перле я бы написал вообще так:

                foo() if (true);
                • +3
                  скобки лишние :-)
                  foo if true;
                  • +28
                    if true — лишнее!
            • +1
              А мне кажется ужасненько, всё-таки табуляцию на «foo();» бы надо.
              • +1
                Подозреваю, её просто съел парсер.
            • 0
              На пхп можно тогда уж перейти в крайность
              if (true):
              foo();
              endif;
        • +3
          Как по мне, то это дело привычки. Для разработки в команде помогают Code Conventions. Если вы пишите сам — то кавычка не является критичным местом.

          Когда лично я пишу код (или просматриваю чей-то), мне всегда приходиться искать открывающую скобку если она находиться в строке оператора, на что тратиться время. Поэтому предпочитаю не использовать «египетский» вариант.
          • +4
            Когда лично я пишу код (или просматриваю чей-то), мне всегда приходиться искать открывающую скобку если она находиться в строке оператора, на что тратиться время. Поэтому предпочитаю не использовать «египетский» вариант.

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

            Еще я заметил, что те, кто ставит египетские скобочки, обычно пишут так:

            if (condition)
            DoSmth();

            или, что вообще ужасно, так:

            if (condition) DoSmth();

            В таких случае у меня глаз за if'ы вообще не «цепляется».
            • +3
              а я заметил, что те, кто не ставит египетские скобки пишут так.

              я предпочитаю только египетские скобки, но так, как вы показали не пишу никогда
              • –1
                может потому так пишут те, кто не ставит египетские скобки?
                • +1
                  те кто пишут скобочку на следующей строке, итак не экономят место, им не жалко лишней строки для скобочки, какой смысл ее игнорировать? это те кто пишут в египетском стиле экономят место (обычно это первый аргумент — экономия строк) так что и проигнорировать закрывающую скобочку за глаза могут, это ведь целая строка
            • –1
              Я всегда пишу if (condition) DoSmth();
              Потому что это фактически один оператор, а индент для меня — явный указатель на под-блок кода.

              Таким образом, если я напишу
              if (condition)
              DoSmth();

              То будет создана ошибочная видимость нового блока.

              Заводить же ради одного оператора новый блок — растягивает код чересчур сильно. На моей скромной девятнашке это не позволяет видеть код целиком в некоторых случаях.
              • +5
                Что-то в вашей консерватории не так.

                1) длина метода больше 20 строк — уже плохо.
                2) Отсутствие скобок означает легко (и часто!) возникающую проблему при поддержке/дописывании кода.

                скобки на следующей строке — без отступа — это православно )
                • +1
                  Я делю код на функции по смыслу. А не потому, что кто-то сказал, что функции должны быть по 8 строк (например). Где-то удобнее функция на 2 строки, а где-то и 40 строк бывает, если она делает одну конкретную неделимую задачу.
                  • +1
                    вторая причина более четко формирует почему отсутствие скобочек — плохо, я сам лично сталкивался с глюками по этому поводу, и ловить их трудно
                    • 0
                      не встречался с этим оО
                      может подскажете? )
                      • 0
                        банально длинное условие в ифе, которое выходит за край экрана, и за ним какое-то действие на следующей строке, и дальше какие-то действия, я думаю что после ифа скобка открывающая, и дописываю что-то нужное мне, проверяю, с первого взгляда работает, но нот фиа не слушается… как-то так
                        • 0
                          «но нот фиа не слушается» — но вот мой код ифа не слушается…
                        • 0
                          Ну так длинные условия надо рефакторить.

                          Например вот так
                          • 0
                            это был не мой иф, код не идеален был, если бы я все изменял бы как нужно, получился бы новый проект + куча времени, что не приветствовалось (время не приветствовалось), так что случаи бывают разные
                            • 0
                              Безусловно, тут вы правы :)

                              Я в основном со своим кодом просто работаю.
                      • 0
                        Когда пишу на PHP, я активно использую аббревиатуру
                        echo "<pre>"; var_dump($varName); echo "</pre>";
                        После написания
                        try {
                        //...
                        }
                        catch (Exception $e) echo "<pre>"; var_dump($varName); echo "</pre>";

                        в эту аббревиатуру добавились фигурные скобки.
                        Думаю, с if что-то аналогичное.
                        • 0
                          Ну тут само собой нужны скобки, т.к. тут три оператора, а не один.
                          У меня такие правила —
                          1. Никогда, НИКОГДА!!! Не писать более одного оператора в строке.
                          2. Стараться не разбивать оператор на несколько строк, если он такой длинный — следует его отрефакторить.
                          3. Если в ифе один оператор — обойтись без фигурных скобок.
              • 0
                А вот отлаживать такой код геморно, особенно когда у вас максимум четыре бриктопинта дебагер поддерживает, и step into не пашет.
                И приходится в таких местах разварачивать это дело в несколько строк.
                Я тоже раньше любил в одну строчку писать, потом желание отпало :)
            • +1
              для таких случаев хорошим решением является перенять стиль из питона:

              if(cond)
                 DoSmth();


              я именно так и делаю, за редким исключением.
              исключение:
              if(cond)
                 DoSmth();
              else return false;
              • +2
                Некошерно как-то. Должно быть единообразие форматирования. Либо переносить оператор после условия на другую строку, либо нет. А у вас кто в лес кто по дрова.
        • 0
          Вообще-то обычно их не отбивают. И вообще редко видел, чтобы отбивали — так чиатемость ухудшается.
      • +1
        > В этом случае я вижу оператор (if) и точно под ним завершающую скобку.
        у вас все операторы if такие короткие?
        • 0
          Разные бывают, но вообще if не должен быть слишком сложным — иначего его чтение затрудняется.
          Если это какой-то сложный объект, то иногда проще вынести логику проверки в отдельную функцию.
          • 0
            это вы скажите тем за которыми дописываешь код, всякое вообще бывает, бывает даже что это не сложный объект, а вообще не объект
      • 0
        А зачем вообще использовать скобки для условий с одним оператором?
        • 0
          Это пример.
        • +4
          Потому что через месяц там может стать два и больше операторов. И вам придется не забыть добавить скобки или достаточно долго ловить баг, при котором в управляющей конструкции выполняется только один оператор, а остальные вне его.
          • 0
            Подпишусь. Всегда ставлю скобки.
      • +7
        В Python'е вопрос скобок решили более кардинальным(и очень удобным) методом :)
        • 0
          Поддерживаю.
        • 0
          Ага.
          Не понимаю, чего многие негодуют, типа их заставляют отступы делать. Все равно же в любом языке (иногда — кроме Perl ;)) индентируют код все.
        • 0
          Не совсем.

          вызов_функции(
              с
              кучей
              аргументов
          )
    • +10
      «Египетские» операторные скобки имхо наиболее приемлимый вид операторных скобок в C-подобных языках. Даже если Стив Макконнелл говорит обратное.
      • –1
        Макконнел как раз рекомендует использовать либо «египетские» скобки, либо такой стиь:
        void foo()
            {
            bar();
            }
        
        • +5
          Макконнел очень суров я смотрю
          • 0
            ну макконелл тогда (может и сейчас) работал в майкрософт.
            откройте сорцы стл визуал с++ (файл мусещк) например.
            там именно такой стиль.
        • +2
          Специально залез в Маконнела, перепроверить и он предлагет сеипл:

          void foo()
          {
          bar();
          }

          • 0
            Прошу прощения.
            void foo()
            {
            bar();
            }
            • 0
              По моему у вас тега pre не хватает
              • 0
                Кармы у него не хватает.
          • 0
            Вобще то, я тоже открывал книгу, прежде чем писать комментарий. Второе издание (Питер 2005) 729 страница:
            Избегайте отсутствия отступов в парах begin-end В стиле форматирования, проиллюстрированном в листинге 31-24, пара begin-end выровнена по границе управляющей структуры, а в выражениях, охватываемых операторами begin и end, сделаны отступы относительно begin.
            Листинг 31-24. Пример пары begin-end, не выделенной отступами (Java)
            //Ключевое слово begin выровнено по границе for. 
            for(int i = 0; i < MAX_LINES; i++ ) 
            {
                //В выражениях сделан отступ относительно begin. 
                Readl_ine( i ); 
                Processl_ine( i ); 
                //Слово end также выровнено по границе структуры for. 
            }
            

            Хотя такой подход выглядит хорошо, он нарушает Основную теорему форматирования, так как не показывает логическую структуру кода. При таком расположении begin и end не являются частью управляющей структуры, но в то же время, они не являются и частью блока выражений, расположенного далее.
            • +2
              маконнел не поддерживает какой либо стиль, он советует выбрать один и следовать ему, а не писать мешаниной
              • 0
                В книге, по крайней мере в моём издании, он предлагает выбирать только из двух вариантов («египетский» и с отступом перед скобкой), ещё один называет приемлимым только в некоторых случаях, и ещё два не рекомендует использовать.
    • +7
      Любят же люди скобки обсуждать… Нам, питонщикам, не понять сути проблемы — она чужда нам.
      А если точнее — не важно, КАК и ГДЕ вы ставите скобки, важно, чтобы оформление было ОДИНАКОВЫМ. Но почему-то не все это знают и понимают…
    • 0
      Присоединяюсь к любителям египетских скобок.
      В этом стиле четко видны блоки.
      1 indent = 1 уровень вложенности.
      • +6
        В чем проблема с вложенностью в
        if (true)
        {
            foo();
        }
        

        ?
        • 0
          Субъективно мне труднее это воспринимать.
          Данный вариант я прочитаю как отдельный «оператор» if (хотя он оператором не является) и отдельный блок без каких-либо условий (синтаксис Си такие блоки позволяет). Меня это путает)
          • –1
            И снова нам поможет tcl ^____^

            Так система писать не разрешит, т.к. перенос строки после {true} — начало нового выполняемого списка.
            if {true}
            {
            foo
            }

            Надо писать так:
            if {true} {
            foo
            }

            или
            if true foo
        • 0
          Пока писал на c++ и c# — пользовался таким стилем. Сейчас перешёл на java и «египетский» мне кажется гораздо нагляднее. Опять же, Макконел в «Совершенном коде» так ругается:
          Хотя такой подход выглядит хорошо, он нарушает Основную теорему форматирования, так как не показывает логическую структуру кода. При таком расположении begin и end не являются частью управляющей структуры, но в то же время, они не являются и частью блока выражений, расположенного далее.
          • +1
            Когда пришлось переходить с C# на Java сломал глаза на скобках. Сейчас чуть-чуть стал привыкать. Но все равно предпочитаю неегипетские — они кажутся гораздо нагляднее и разбираться в чужом коде проще
      • +3
        C египетскими скобками вижу одну сложность: когда условие if очень длинное и разбивается на несколько строк, часто в коде видишь что-то типа:
        if (a && b && c &&
        d && e && f) {
        blah-blah-blah
        }
        и как-то сложно понять, особенно если строки длинные, где еще условие, а где уже код. А так это вопрос привычек и личных предпочтений, который в пределах компании решается Code Convention'ами и Style Guide'ами.
        • +1
          обычно это решается двойным отступом при переносе условия:
          if (a && b && c &&
                  d && e && f) {
              blah-blah-blah
          }
          

          тоже не очень красиво, но привыкается быстро.
        • +2
          Когда условие if становится очень длинным, это свидетельствует об том, что пора заняться рефакторингом кода. К примеру провести «выделение метода» или поискать возможность включения граничных операторов, но главное что не писать таких монстров.
        • +4
          Когда условие длинное, лучше сделать так:

          bool goodWeather = noRain && noSnow && noWind;
          bool goodTemperature = (15 < temperature) && (temperature < 30);
          if (goodWeather && goodTemperature) {
              // do smth.
          }
          
        • 0
          if( correctCondition() ) {
          blah-blah-blah
          }

          это не проблема
          • +1
            if (correctCondition(a, b, c, d, e, f, g, h, i, j))
            ?)
            • +2
              (if (and a b c d e f g h i j)
              (blah-blah-blah))

              ;)
            • 0
              например вот так:
              array = [a,b,c,d,e,f,g,h,i,j, ...]
              if( correctCondition(array) ) {
              blah-blah-blah
              }

              суть не в коде, а в том чтоб вынести проверку в сторону
              • 0
                А потом
                correctCondition(array a) {
                return (a[0] > a[1] || a[2] < a[3]) && (a[4] >= a[5]);
                }
                • 0
                  Я повторюсь: дело не в коде, не в реализации, как вы сделаете проверку мне не важно, в данном случае так сработает, просто суть в том чтоб вывести проверку отдельно
    • +2
      А я вообще без скобок пишу :)

      def method
      #…
      end

      и очень этому рад :)
      • 0
        таб потерялся перед #
    • +3
      Раньше тоже ставил египетские, но потом заметил, что после первой скобки всегда оставляю пустую строку. Т.к. пустые строки немного раздражали, я подумал: а почему бы туда не ставить скобку? Вот так я и стал curly-bracket-on-the-next-line man =)
  • +3
    Больше посмеялся, чем культурно обогатился :)
  • +1
    Из ссылки на стековерфлоу еще понравилось это, весьма точное сравнение:

    • +61
      • +6
        Ну для языков, где разрешено присваивание в if это еще может иметь смысл, для защиты от опечаток и недопечаток.
        • –1
          Именно потому так и пишут некоторые продвинутые программисты.

          Константе значение присвоить не получится, а потому компилятор ругнется, если не будет хватать одного "=".
          • +2
            а помоему нынче это уже глупо.
            читается именно в йода стиле, а на присваивание в ифе любой приличный компилятор даст ворнинг.
            • 0
              В интерпретируемых языках нет ворнингов. Но всё равно при определённой квалификации программист будет автоматически два раза нажимать на «=» при написании условия.
              • 0
                perl даёт warning при таком присваивании.
            • +1
              Да это всегда было глупо. Если человек подразумевает вероятность ошибиться в довольно хорошо различимых объектах (ну разве что «привет, паскалистам»), то что уж говорить про менее тривиальные вещи. Напротив, излишняя концентрация на условиях позволит сделать их более аккуратными, а ведь условные ветки всегда сложнее отлаживать, чем последовательность операторов.
        • +1
          Да, это я знаю. Мне сравнение понравилось :).
        • +1
          Запрет присваивания в if приведёт к хитросплетённому и нелогичному синтаксису. На самом деле это проблема для языков, приводящих всё к int и ожидающих везде int (т.е. C :]).

          В D if ожидает boolean, так что if (count = 5) не сработает, а if (b = (count == 5)) — сработает. Или даже if (bool b = count == 5)
          • 0
            В интерпетируемых динамически-типизированных языках часто идет проверка не на равенство с чем-то, а на непустое значение, при этом нет смысла проверять, что a <> 0, a<>"" и т.п. — для простоты хочется иметь очень простую проверку подходящую для любого типа:
            if (a) {}
            • 0
              И на что это должно проверять, в случае, например, строк? На пустую строку или на null?
              • 0
                На значение, то есть не пустая строка и не нулл.
                • 0
                  Пустая строка — не значение, ноль — не число?
                  • 0
                    Это в общем плане. А в конкретном это выглядит так: если тебе пришло, скажем 0 комментариев, или число комментариев оказалось не задано (что обозначает отсутствие данных), то нужно скрыть блок комментариев.
                  • 0
                    Если тебе не нравится встроенное приведение к bool, всегда можно проверить на равенство null.
                  • 0
                    это называется приведение типов, 0 — фолс, -1 — тру, итд… не нравится? == и вперед перечислять что хочешь видеть на самом деле
                    • 0
                      Горшочек, не вари! Давайте больше не будем продолжать играть в К.О. :)
                      Моя мысль была в том, что может быть не всегда очевидным, что делает простое «if (a)». Особенно в случае нестандартных типов и перегрузки приведения к bool.
                      • 0
                        я понял что вы имели ввиду, я к тому что преобразования в 99% очевидны для каждого компилятора/интерпретатора, надо лишь знать нюансы языка с которым работаешь
          • +1
            Без присваивания в if простой код вида

            while ((len = read( td, rbuf, 250 ))!= -1){

            Превращается в нечто весёлое.

            P.S. Да, я любитель египетских скобок :)
            • 0
              здесь это допустимо, а вот любители писать для красоты:

                while((bRet = GetMessage( &msg, hWnd, 0, 0 )) != 0) {
              

              немного огорчают, ибо случай bRet == -1 тоже существенен. И вот тут-то начинается совсем другое веселье…
        • +1
          В PHP иногда пишу что-то вроде
          if ($a = $b[$c]) {//Присваивание, а не сравнение

          Но в таких случаях всегда стараюсь писать комментарий, что присваивание — это не опечатка.
          • 0
            а я стараюсь присваивать прям перед ифом во временную переменную, и потом совать ее в иф, для наглядности можно ее сразу же убить после ифа
          • 0
            У. Р. Стивенс в своих книгах исповедует такой вариант:
            if ( (x = assignment_expression) == value) {
                 // expression
            }
            


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

            Вариант без присвоения пишется как обычно:
            if (condition == value) {
                 // expression
            }
            

      • НЛО прилетело и опубликовало эту надпись здесь
      • –1
        Это все юмор от незнания.
        Как и выше упомянутые вами «египетские скобки», вполне имеющие право на жизнь, и являющиеся одним из множества стандартов написания кода. Спорить о том, куда лепить скобку, бессмысленно — слишком это мелочно.
        А касательно Йоды: вам не нравится, что число перед переменной? Вы просто не в курсе, что это превентивная мера, часто спасающая от ошибки if (count = 5).
        Вы еще наверное не в курсе, что в некоторых языках if может быть справа от выполняемого действия? Например, a = 3 if b == 5.
        • +3
          дело не в нравится/не нравится, никто никого не осуждает. дело в названиях. читай заголовок
        • +1
          Вы невнимательно читаете. Во-первых, я не говорил, что египетские скобочки не имеют права на жизнь — я просто высказал свое отношение к ним. Во-вторых, я уже написал, что я в курсе, зачем константу пишут перед переменной; меня в этой картинке позабавила исключительно точность сравнения.
        • 0
          Как по мне, Йода стайл применим еще в таком случае:

          emum Foo{...}

          if (Foo.FooTheFirst == myVariable)
          {

          }

          В таком случае оператор if больше напоминает оператор switch — немного улучшается читаемость. Ну… Это когда switch использовать нельзя. Также применимо для конкретных случаев и является делом вкуса.
      • +20
        Речи Йоды тайна раскрыта, старый на Форте программист оказывается он.
      • +2
        у меня почему-то такой стиль в SQL прижился
        SELECT * FROM t1 WHERE x=42 AND 0=(SELECT COUNT(*) FROM t2 WHERE t1.a=t2.b)
        • +1
          Потому что подзапрос идёт в самом конце и не смешивается с логикой основного запроса, я правильно понимаю?
      • +5
        5 count == if ... else ... then
        Йода-стайл, Форт.
        • 0
          Очень часто можно его найти и в проектах на Perl.
      • 0
        такая запись даже является стандратом в некоторых code guidlines, например в симфони для пхп
      • 0
        Настоящие джедаи пишут
        if Count = 5 then
        • +2
          Настоящие джедаи пишут
          CMP Count, 5; или как там было сравнение, не помню уже
          • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Странно, что в топике этого нет, самая крутая тема из того треда на StackOverflow.
      • 0
        Ну как бы в некоторых языках это справедливо. И никакой это не стиль Yoda, а совершенно разумное убирание одних граблей в сторону.

        Попробовал в двух основных для себя языках сейчас. Увы и ах )

        exp.go:3: z = 3 used as value

        >>> if z = 3: print('asd')
        File "", line 1
        if z = 3: print('asd')
        ^
        SyntaxError: invalid syntax
  • 0
    Спасибо. Но иногда тонко…
  • +4
    Здорово! Осталось найти ту заразу, которая рассказала про Fear-driven development нескольким моим знакомым ПМам, и ту, которая в проекте, с которым я сейчас работаю, решила использовать String typing… Но по крайней мере, теперь я знаю, как это называется! :-)
    • +2
      tcl избавит вас от всех проблем ;)
      • 0
        Тогда уж РЕФАЛ
  • +3
    Очень ощущается отсутствие художественности перевода. Многие шутки останутся непонятыми.
  • 0
    О да!.. Просто прекрасно!
  • 0
    очень забавная статья получилась, спасибо, улыбнуло.
  • +1
    >>> Тестировщик: Да… пожалуй
    Уволил бы такого сразу, нормальный тестировщик использует все пальцы включая даже не пальцы, лишь бы воспроизвести найденный раннее глюк.
    • +3
      Я неожиданно понял, что лучше было бы иметь сектор тестирования из двух молодых людей, а не из двух барышень, как у нас сейчас.
      • –1
        Интересно послушать ваши аргументы.
        • +7
          Больший диапазон «даже не пальцев» для тестирования? :-)
        • 0
          На самом деле иногда тестировщику так хочется заехать в ухо за редкостный талант поиска багов, а вот глядя на милое личико барышень из отдела тестирвоания такого желания не возникает.
      • +1
        Сектор тестирования надо иметь из двух обезьян. И чем нахальнее они будут, тем лучше :)

        Тестировщики, без обид :) Это восхваление профессиональных навыков, а не высмеивание %)
  • 0
    Шикарно! Но, к сожалению, увидел много знакомого.
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Оказалось, что я все это уже видел :)
    Спасибо!
  • 0
    Пусть пользователи будут тестировщиками <...>

    Почти прямая цитата Грега Кроа-Хартмана с Google Tech Days. Грустно.
    • +3
      и почему же грустно?)
      вы ни где не получите фидбека кроме как от живых пользователей
      и эта фраза не означает давайте выпустим на рынок говно
    • +2
      Не очень то и грустно на самом деле. Хоть тестировщики в штате и хорошо, они всего лишь выполняют свою работу. А вот пользователи используют программу. И им всё же зачастую виднее, что сделано не так.
    • 0
      Как по мне, этот подход очень даже подойдет в продуктах без, если можно так выразиться, четко утановленных требований, в результате сложно оценить необходимость добавления или устранения каких-либо «фич». В этом случае пользователи-тестеры помогут как никогда лучше и будет совсем не грустно.
      • 0
        Это называется «путь мягкого ввода», т.е когда цель первыми выпустить продукт (например какой нибудь web-сервис) потому что глюки (если они мелкие) можно отловить и позже, а вот если не успеть с выпуском до того как конкуренты выпустят аналогичный сервис, то убедить пользователей переходить на ваш сервис будет уже труднее…
  • +18
    «Тестировщик: Модуль X не работает корректно
    Разработчик: Должно быть раньше вы использовали неправильный палец.
    Тестировщик: Да… пожалуй..»

    Для владельцев новых айфонов 4G весьма актуально, пожалуй)
  • +3
    Паттерн документирования «Буказоид» предлагаю переименовать в «Капитан Очевидность»
    • +1
      Может, "Сепульки"?
      • +1
        Я сужу по примеру кода, иллюстрирующему паттерн
    • 0
      Тогда уж так :)

      // class comment
      /**
      * Bukazoid manager is a manager to manage bukazoids.
      */
      public class BukazoidManager extends SomeOtherClass { // class definition
      ...
      } // end of class body
      
      • 0
        Последний комментарий может быть полезен иной раз.
  • +12
    > Нажимай сильнее / Неправильный палец / Правильно держи мышку

    — Мне нравится мой новый iPhone 4 (отличная работа), но когда я касаюсь рукой металлического канта, сигнал пропадает. Это похоже на распространённую проблему. Есть какие-нибудь планы по её исправлению?

    — Просто старайтесь не держать его таким образом

  • +2
    РеФАКторинг — чудесный метод!

    Что из оригинала еще улыбнуло:
    Bloombug
    A bug that accidentally generates money (just did this one)
    — полезно :), но не всегда ненаказуемо.

    Из комментариев:
    I always thought «excrement» should have been the opposite of increment
    • 0
      Из оригинала часто встречаюсь с «Ninja Comments»
  • +12
  • 0
    Я всегда открывающую скобку ставлю сразу после функции / условия, следом коротенький однострочный коммент типа того

    function blablabla() { // она самая
    action;
    }
  • +17
    Дарвиновское программирование/Экспериментальное программирование
    Изменение кода(как правило, случайное) без понимания смысла изменений, пока он не заработает. Например, замена инкремента на декремент.

    вот здесь я узнал себя…
    • +8
      Тут, Игорь, многие себя узнали. Просто мало кто в этом признается… :-)
    • +2
      оказывается я не одинока :)
      • 0
        нас много.
        • +3
          Особенно, когда видишь баг типа «не сходится на… 10», а в коде что-то типа "… =… +5;" появляется дикое желание поменять "+" на "-".
    • +3
      Я так на олимпиадах пишу. Что интересно — иногда срабатывает.
      У меня этот метод делится на 2 способа:
      1. Куча переменных с непонятными именами, пробовать в каком-нибудь месте поменять одну переменную на другую.
      2. О, а если то, что получилось, умножить на 2 и прибавить 18, то мы получим правильный ответ! Так, сделаем еще несколько тестов… Да, так и напишем.
      • +3
        И пусть потом рассказывают, что олимпиадники классные программисты…
        При найме для меня это будет некоторым плюсом, но никак не решающим.
        • 0
          Ключевые слова — на олимпиадах
          В спокойной обстановке я как правило код пишу по-другому:)
          А олимпиады приучают быстро анализировать задачу и придумывать хороший способ решения. Важно после этого не бросаться писать, а чуть-чуть подумать, как эффективнее реализовывать.
          • +1
            Извиняюсь, недосформулировал мысль до конца. Я встречал мнение, что если человек хорошо выступал на олимпиадах, то его можно брать «не смотря». Я же считаю, что никакой однозначной корреляции между «хороший олимпиадник» и «хороший разработчик» не существует.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Ошибка, подчиняющаяся принципу Гейзенберга — очень ок :)
  • +3
    JFDI(just fucking do it) — методика разработки часто применяемая после срыва сроков
  • +2
    Вчера занимался дарвиновским программированием — нужно было реализовать один алгоритм, который должен был нечто рассчитать, заказчик на вопрос каким образом это нужно рассчитать только мычал в трубку и приводил кучу взаимоисключающих примеров. Пришлось писать фигню и исправлять ее по мере того как заказчик уточнял задание:)
    • 0
      Вы знаете, у меня подозрение что 99% всех бухгалтерских пакетов пишется именно таким образом
  • 0
    Метод Перкова очень похож на нисходящее программирование Вирта, и оно мне нравится. Просто не надо писать сочинения на тему.
  • +3
    Что-то в статье притянуто за уши, что что-то просто вызывает протест. Например, в разделе «Очень ориентированное программирование(ООП, Over Oriented Programming)» приведена схема синтаксиса языка Javascript. Это самая компактная и наглядная запись спецификации. К ООР она не имеет ну ни малейшего отношения. (больше информации на пример тут blog.nicksieger.com/articles/2006/10/27/visualization-of-rubys-grammar и ещё 1001 месте)
  • 0
    Пинг-понг понравился :) Как раз в тему с айфоном новым)
  • +3
    «TDDD: Technical Debt-Driven Development» переводится как «Разработка управляемая 'техническим долгом'».

    То есть, когда разработчик постоянно откладывает фиксы и улучшения в коде «на потом».
    • 0
      Спасибо, исправил
  • 0
    «TDDD: Technical Debt-Driven Development
    Разработка, управляемая техническими сомнениями»

    TDDD: Technical DOUBT-Driven Development ???
    • 0
      Возможно.

      Потому что концепция Technical Debt (http://www.martinfowler.com/bliki/TechnicalDebt.html) принадлежит «светлой стороне силы», уменьшение долга улучшает код в отличие от остальных приведенных методов.
  • +1
    frAGILE
    до чего ж знакомо-то…
  • 0
    while (2
  • +8
    Вывели с коллегами IDD- Imagination Driven Development.
    Нет документации, нету user story, нету ничего. Только ты, IDE и твое воображение.
    • 0
      Задачи, поставленной начальником, то же нет? Тогда завидую.
      • 0
        Задача обычно ставится примерно так: "#ля! надо чтобы было к следующему понедельнику! Придумай что нибудь" или «Нужно сделать креативный дизайн по типу этого» или «сделай как у <вставить название>»
    • 0
      Хаха, Макс, это круть :)
  • +7
    Недавно услышал термин «demo-oriented development» — это когда в процессе разработки приходится переодически демонстрировать результаты начальству, и целью становится не работающая программа, а такая, которую «лишь бы продемонстрировать». Часто для этого приходится даже тщательно подбирать последовательность действий, чтобы программа не вылетала и не провалила демонстрацию.
    • +5
      Это универсальный принцип, применяемый к любым продуктам, плюс побольше рюшечек и свистоперделок
  • +3
    Йооопт! Тащу в блог =))) Это все надо перевести и задокументировать!

    Hydra Code
    Code that cannot be fixed. One fix causes two new bugs.
    It should be rewritten.

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

    • +6
      Ох, что-то картинка великовата. В качестве извинения — переводы других забавных вещей:

      Pokemon Exception Handling — Поймай их всех

      Google Code — 5-10 строк кода, найденных после трех часов гугления, которые вы боитесь поменять, т.к. использующийся там API нелогичен и черезмерно сложен.

      Loch Ness Monster Bug (Лохнесский баг) — невоспроизводимый баг, который видел только один человек.

      Megamoth (MEGA Monolithic meTHod) — Мегамонолитный метод, как правило сидящий внутри Божественного объекта/класса, простирающийся на 2 экрана и более. Были замечены мегамоты высотой в 2000 строк кода =)
      • 0
        Google Code может быть еще отнесен к MSDN cookbook %) Тупо идем на мсдн, в поиске выбираем первое решение и перекрестясь копипастим. Быстрее компилируем и главное не заглядываем внутрь =) Holy code же.
  • +6
    судя по количеству комментариев про «ебипетские скобки» дальше никто не читал…
    • +4
      Читали, просто не пишут коментариев, ибо скобки это куда более животрепещущая тема которую хочется обсудить…
  • 0
    Хабраюмор?
  • 0
    Никто не знает, как они такую картинку получили?

    И для какого это языка.
    • +1
      По-моему, эта картинка там просто для красоты. Где-то я уже ее видел. И если не изменяет память, это описание того, как в Windows происходит системный вызов. Либо Windows, либо Linux. Их там где-то в сравнение приводили. Давно было дело.
    • +3
      Похоже на творение graphviz'овского dot. А в комментах выше уже сказали, что это схема то-ли лексера, то-ли парсера Javascript'а.
    • НЛО прилетело и опубликовало эту надпись здесь
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      А что, отступы он принципиально не применял? Или он код писал исключительно на бумажке? :)
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Ну за это надо как бе расстреливать сразу. Люди сказали бы спасибо
          • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Наши программисты на вопрос — какой ваш любимый паттерн отвечают- паттерн
    «костыль»
  • 0
    Мне ещё понравилось:
    Yoda condition:
    if (42 == value) {
    // …
    }

  • 0
    О Боже! У меня синдром перкова, надо лечиться.

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