Какой стиль написания/оформления кода вам ближе?

     
    Какой стиль написания/оформления кода вам ближе?
    • 29.5%Лаконичный — где мало строк, но каждая из них несет полезную нагрузку и выполняет максимум возможных операций206
    • 57.5%Скурпулезный — где много лишних строк, но все красиво, подробно, гламурно и упорядоченно401
    • 12.9%Мне все равно90

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

    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 53
    • 0
      Стиль «отсутствие стиля» not detected :)
      • –1
        В этом вся фишка. Каждый хотя бы в подсознании склоняется к чему-то одному, и задача опроса — отсечь среднее и выяснить правду-матку.
        • 0
          А третий вариант разве не подходит? )
          • 0
            Нет :) Есть именно отсутствие стиля, т.е. «каша»: из операторов, символов, скачущие строки, разнобой выравнивания, лишние пробелы и т.п.

            Мой предыдущий начальник смотрел даже на количество пустых строк между объявлением методов, чтобы оно было одинаково для всего файла и всех файлов. Мотивация следующая: «как можно доверить что-то серьезное человеку, который даже не может вставить одинаковое количество переводов строки?»

            :)
        • НЛО прилетело и опубликовало эту надпись здесь
          • НЛО прилетело и опубликовало эту надпись здесь
            • +2
              К холивару готовы? :)
              • НЛО прилетело и опубликовало эту надпись здесь
            • НЛО прилетело и опубликовало эту надпись здесь
              • +3
                Вас зарезал злобный хабрапарсер :)
                • +2
                  Вы извините, но в этом случае еще приятнее просто
                  Hello
                  
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      Да. Только что проверил. Ну еще путь к интерпретатору можно добавить.
                • 0
                  (defined($style{compact}) && defined($style{smart})) || warn «Bad style»;
                  • 0
                    Для control flow рекомендуется использовать or и and вместо || и && :).
                    • 0
                      defined $style{compact} and defined $style{smart} or warn 'Bad style';

                      Нет лишних скобок, двойные кавычки заменены на одинарные, поскольку строка не содержит переменных.
                      • 0
                        Вот тут есть спорные моменты. Некий Ларри Уолл советует расставлять скобки «побольше». Хотя без скобок мне тоже нравится больше :) А про and/or, имхо, в данном случае дело вкуса. У && || приоритет выше, но в данном случае это не играет роли. Кому как нравится :)
                        • 0
                          А можно ссылочку? Вот документ от меня по теме:
                          perldoc.perl.org/perlstyle.html
                          А конкретно: «Omit redundant punctuation as long as clarity doesn't suffer.»
                          • 0
                            Ошибся, это он о других скобочках, запамятовал совсем
                            books.google.com/books?id=ezqe1hh91q4C&printsec=frontcover&hl=ru
                            вот тут, на странице 264

                            • 0
                              И даже там я не увидел призыва ставить побольше скобок — любых :).
                    • +1
                      Ни то и ни другое. Надо что-то среднее. С одной стороны, сокращения очевидных операций и алгоритмов еще никому не повредили, но и с фанатизмом подходить к этому вопросу не стоит.
                      • +1
                        Если первый вариант, это что-то типа такого:

                        $string = trim(str_replace($pattern, $replacement, preg_replace($preg_pattern, $preg_replacement, $string)));

                        То я — за второй.
                        • 0
                          Да, это укладывается в рамки первого варианта.
                          • +2
                            А с другой стороны, если тот-же код написать на питоне:

                            str = re.sub(re_pattern, re_replacement, str).replace(pattern, replacement).strip()

                            То нормально.
                            Пожалуй, все зависит как от языка, так и от конкретных задач.
                          • –1
                            Если нормально отформатировать имхо вполне читаемо, но перегибать с такими вложениями не стоит.
                            $string = trim(
                            	str_replace(
                            		$pattern, 
                            		$replacement, 
                            		preg_replace(
                            			$preg_pattern, 
                            			$preg_replacement, 
                            			$string
                            		)
                            	)
                            );
                            
                            • +1
                              А вот теперь представьте, что вам в процессе отладки захотелось посмотреть, что вернул preg_replace…
                              • +1
                                Если бы это был С/С++ и MS VS, то step in preg_replace, step out и в окошке Auto вы бы увидели, что вернула функция, из которой вы вышли. Отладчики PHP так не умеют?
                                • +1
                                  Не в курсе, я не пишу на PHP. Должны, по идее.

                                  В любом случае, я за такие конструкции бью по рукам. Как и за if-ы без скобок, chained calls (method1().method2().method3()), присвоения в if-ах и вообще различный obscured и error-prone код.
                                • 0
                                  да без проблем:


                                  $debug_value = preg_replace()


                                  echo $debug_value;
                                  • 0
                                    т.е. код станет вот такой?

                                    $debug_value = preg_replace(
                                    $preg_pattern,
                                    $preg_replacement,
                                    $string
                                    )

                                    $string = trim(
                                    str_replace(
                                    $pattern,
                                    $replacement,
                                    $debug_value
                                    )
                                    );

                                    А после того, как посмотрели — вернете все обратно?

                                    И чем это лучше, чем сразу вынести результаты в переменные?
                                    • 0
                                      зачем же так? Код станет вот таким:

                                      $string = trim(
                                      str_replace(
                                      $pattern,
                                      $replacement,
                                      $debug_value = preg_replace( // look here
                                      $preg_pattern,
                                      $preg_replacement,
                                      $string
                                      )
                                      )
                                      );
                                      • 0
                                        Да, уже проверил.

                                        Жуть.
                            • 0
                              по настроению
                              • 0
                                Когда увеличение размера кода мало влияет на производительность программы — описываю всё подробно. Иногда приходится перечитывать собственные исходники через пару лет, и тут лаконичность пониманию не способствует. Внедрение пары временных переменных в таком случае — приемлимо, я считаю.
                                А вот когда приходилось писать на ассемблере (это было давно и неправда), тут никаких лишних строчек не допускалось; для асма работает правило «чем короче, тем понятней».
                                • 0
                                  Ключевое слово — чтобы все было понятно и не вызывало вопросов ни у тебя, ни у членов команды.
                                  • 0
                                    «Лаконичный» — это когда одну строку всё через точку с запятой? :-)
                                    • 0
                                      Отчасти — вплоть до комментариев. Но в разумных, разумеется, пределах.
                                    • 0
                                      Хорошо красиво написаный код удобно поддерживать. Особенно если его написал не ты. Особенно если пять лет назад. Особенно если документации нет, как нет и человека, который это писал, а это все надо срочно править.
                                      • 0
                                        … и плевать что в исходнике много «лишних» вроде бы строк.
                                        • –1
                                          А скроллить не надоедает? Особенно если на нетбуке каком…
                                          • 0
                                            Большинство современных IDE имеют возможность сворачивания кода, а без нее даже лаконичный код читать не шибко-то удобно.
                                            • +1
                                              Заниматься программированием на нетбуке — это извращение.
                                        • 0
                                          А где же вариант «где мало строк, но каждая из них несет полезную нагрузку и выполняет оптимум (а то и минимум) возможных операций»? Ну или «код, который выполняет ровно то, что нужно»
                                          • 0
                                            Вам в первый вариант, он это, по идее, и подразумевает…
                                            • 0
                                              Может и подразумевает, но «максимум возможных операций» — это то, от чего мы доооолго избавлялись. Люди не всегда понимают, что «максимум» не всегда нужен, а зачастую даже наоборот.
                                          • +3
                                            Который соответствует code convention. Я программы не для себя пишу, а для людей, и единый стандарт оформления сильно облегчает нам всем жизнь.
                                            • 0
                                              Люблю все красиво оформить и подробно расписать, причем фанатично предан своей позиции, я считаю что некрасивый, неудобный для прочтения код, по определению не может хорошо работать, так как шанс допустить в нем ошибку на порядок выше. Да и вообще должно-же быть в нашей профессии что-то красивое… :P
                                              • +1
                                                К слову, «скрупулёзный». Это — очень распространённая ошибка.
                                                За него и проголосовал.
                                                • –1
                                                  Настолько распространенная, что впору менять грамматику. :(
                                                  • +1
                                                    Нужно в школе учиться скрупулёзнее, а не грамматику менять.
                                                • 0
                                                  Как тут уже сказали, принятые в проекте правила стиля прежде всего.
                                                  Краткость — не самоцель. Но красивый и понятный — не значит раздутый.
                                                  Я стараюсь минимизировать плотность побочных эффектов. Если цепочка из нескольких вызовов описывает понятный data flow, значит место ей в одном операторе. Эмпирический критерий: у промежуточного значения должно быть понятное и быстро придумываемое название, чтобы его имело смысл вынести в переменную.
                                                  В языках, где с выражением подобных абстракций туго, придерживаюсь verbose стиля.
                                                  В общем, стиль должен быть адекватен возможностям языка. Возможностям команды тоже, но это уже другой вопрос.
                                                  • 0
                                                    Как-то привык уже оформлять код относительно красиво )
                                                    Вместо табуляции использую два пробела. Не знаю, хорошо ли это, но читается достаточно удобно.
                                                    • 0
                                                      А я наоборот отказался от двойного пробела в пользу табуляции, так как табуляция — это все-таки специально предназначенный для этого символ, который к тому-же в большинстве современных редакторов кода можно настроить самостоятельно, например на те-же два пробела, это способствует тому чтобы у другого программиста, открывшего этот код, он отображался чуточку ближе к его собственным предпочтениям.

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

                                                    Интересные публикации