Комментарии 63
Лучшый?
На перле можно каждый второй скрипт отправлять на конкурс. Место в тройке гарантированно.
Распространенное заблуждение ;)
Perl отлично читаемый язык, правда перенасыщенный идиомами, посему сложный для вкуривания без его знания. И использующий явные указатели, что для многих программистов бывает… некомфортным. Меня например PL/SQL после перла бесит своей нелаконичностью. В итоге конструкция из пары строчек (научиться читать map / slit / join конструкции и простейшие регекспы несложно).
Хотя вы правы, нечитабельны именно скрипты, когда мне надо что-то быстро сваять, например прогу для чистки raw/jpg, я не особо парюсь читабельностью и тем что конструкция ?(): не является общепринятой идиомой.
Правда и питоновских подскриптников у меня хватает и тоже не сказал бы что они читаемые ;)
Да вот и пример — приблуда которая переносит в каталог 2clear (корзину) JPG файлы не имеющие RAW пары с тем же именем.
Perl отлично читаемый язык, правда перенасыщенный идиомами, посему сложный для вкуривания без его знания. И использующий явные указатели, что для многих программистов бывает… некомфортным. Меня например PL/SQL после перла бесит своей нелаконичностью. В итоге конструкция из пары строчек (научиться читать map / slit / join конструкции и простейшие регекспы несложно).
Хотя вы правы, нечитабельны именно скрипты, когда мне надо что-то быстро сваять, например прогу для чистки raw/jpg, я не особо парюсь читабельностью и тем что конструкция ?(): не является общепринятой идиомой.
Правда и питоновских подскриптников у меня хватает и тоже не сказал бы что они читаемые ;)
Да вот и пример — приблуда которая переносит в каталог 2clear (корзину) JPG файлы не имеющие RAW пары с тем же именем.
use strict;
use Data::Dumper;
my @files = glob('*.*'); # опасность ищем только файлы с расширениями
my %refs = ();
my %param = (
clear => ['jpg'], # страшная конструкция ключ => ссылка(!) на анонимный массив
base => ['raw','nef','dng'],
);
for my $f (@files){
next unless $f =~ /([^\\\/\:]+)\.(.*?)$/; # страшный регексп(!) для выкусывания имени файла и расширения
my ($name, $ext) = (lc($1), lc($2)); # непонятные переменные $1 $2 для результатов поиска
$refs{$name}{$ext} = $f; # хэш-хэшей (нужно помнить что скобки массива и хэша разные)
}
for my $r (keys %refs){
next if grep{ exists $refs{$r}{$_} } @{$param{'base'}}; # постфиксный if, избыточный grep и разыменование "ссылки на массив" (!) в массив
for (map{ exists $refs{$r}{$_} ? $refs{$r}{$_}:() } @{$param{'clear'}}){ # map cond?():value для исключения эл-тов из массива с одновременным его преобразованием
rename($_, "2clear/$_"); # опасность! переменная $_
}
}
Главное, чтобы такое не пролезало в продакшн. Пишу на перле реальные проекты уже достаточно долго, проскакивали у нас такие вещи у новых программеров. Но благодаря настроенному Perl::Critic, жить становилось проще всем.
А что именно вам тут не нравится? ;)
Здесь использована одна нестандартная идиома. Кстати Perl::Critic на неё почему-то не возбудился.
Что нашёл Perl::Critic в brutal mode (в gentle ему всё нравится):
— Объявлять ревизии и пакеты в скипте, равно как возвращать 1 в конце оного я вижу мало смысла.
— next unless я сам не люблю, но тут абсолютно читаемый контекст (свалить, если регэксп ничего не нашёл). постфиксный if я считаю более читабельным, чем префиксный (что кстати в соглашении о коде на прошлой работе было прописано).
— grep — as bool да моветон, но в данном контексте допустим. List::Util::any — смысла мало тут городить.
— скобки в вызове built-in функций… вот это сюрприз — предпочитаю их писать для более легкого чтения кода
Так что про «новых программистов» вы загнули, 6 лет плотной работы с Perl оно знаете как-то…
Здесь использована одна нестандартная идиома. Кстати Perl::Critic на неё почему-то не возбудился.
Что нашёл Perl::Critic в brutal mode (в gentle ему всё нравится):
— Объявлять ревизии и пакеты в скипте, равно как возвращать 1 в конце оного я вижу мало смысла.
— next unless я сам не люблю, но тут абсолютно читаемый контекст (свалить, если регэксп ничего не нашёл). постфиксный if я считаю более читабельным, чем префиксный (что кстати в соглашении о коде на прошлой работе было прописано).
— grep — as bool да моветон, но в данном контексте допустим. List::Util::any — смысла мало тут городить.
— скобки в вызове built-in функций… вот это сюрприз — предпочитаю их писать для более легкого чтения кода
Так что про «новых программистов» вы загнули, 6 лет плотной работы с Perl оно знаете как-то…
Что не нравится?
Ну например вот это:
или это
или
Это трудно читается. У нас над одним кодом работают 10 перл-программеров, если каждый будет писать как захочет, это будет полный ад.
Помимо того, что нужен один(или хотя бы похожий) стиль программирования (а особенно в таком языке, как перл, который позволяет слишком много вольностей).
Кстати, да, забыл, помимо перлкритика у нас еще хук на push стоит в репозиторий, который проверяет код на всякие мелочи.
Так вот, помимо общего code-style, как я считаю, необходимо просто-напросто запрещать некоторые конструкции (у нас например запрещены постфиксные if-ы, в которых больше 2 условий; или например однострочные map-grep-sort; или например вложенные тернарные условия; ну и так далее).
Всё-таки согласитесь, что на перле гораздо проще написать трудночитаемый код не говнокодя, чем на тех-же плюсах или джаве.
Я сам не так давно страдал этими конструкциями(до сих пор иногда проскакивает :), но переучил почти себя, стало немного проще читать свой код 1-1.5годовой давности :)
Ну например вот это:
next if grep{ exists $refs{$r}{$_} } @{$param{'base'}};или это
for (map{ exists $refs{$r}{$_} ? $refs{$r}{$_}:() } @{$param{'clear'}})или
next unless $f =~ /([^\\\/\:]+)\.(.*?)$/;Это трудно читается. У нас над одним кодом работают 10 перл-программеров, если каждый будет писать как захочет, это будет полный ад.
Помимо того, что нужен один(или хотя бы похожий) стиль программирования (а особенно в таком языке, как перл, который позволяет слишком много вольностей).
Кстати, да, забыл, помимо перлкритика у нас еще хук на push стоит в репозиторий, который проверяет код на всякие мелочи.
Так вот, помимо общего code-style, как я считаю, необходимо просто-напросто запрещать некоторые конструкции (у нас например запрещены постфиксные if-ы, в которых больше 2 условий; или например однострочные map-grep-sort; или например вложенные тернарные условия; ну и так далее).
Всё-таки согласитесь, что на перле гораздо проще написать трудночитаемый код не говнокодя, чем на тех-же плюсах или джаве.
Я сам не так давно страдал этими конструкциями(до сих пор иногда проскакивает :), но переучил почти себя, стало немного проще читать свой код 1-1.5годовой давности :)
По поводу for полностью согласен — грязный хак. for на map да еще неявный filter. писалось для себя, а сам я знаю какие идиомы хорошо читаются ;)
По поводу постфиксного if с одним условием не соглашусь (вот постфиксный unless с двумя условиями или даже одним, не совсем прозрачным — первый кандидат на выпил).
Мне легче прочитать постфиксный if с правильным форматированием, чем префиксный. Это более логично и хуманоридабельно:)
По поводу постфиксного if с одним условием не соглашусь (вот постфиксный unless с двумя условиями или даже одним, не совсем прозрачным — первый кандидат на выпил).
Мне легче прочитать постфиксный if с правильным форматированием, чем префиксный. Это более логично и хуманоридабельно:)
Дать васе пряник
если
сегодня вторник
и сегодня шел дождь
и у нас есть пряник
и (вася себя хорошо вел
или вася застукал меня с училкой
или у меня хорошее настроение);
Ну вот кстати по поводу питона соглашусь. Например мне его сложно читать, после нормальных языков )
Это как раз плохой код. Почему «выкусывание» имени файла не заменить на вызов нормальной функции типа basename()/parseFilename()?
> for my $f (@files)
Лишь бы не писать нормально, for ($var in $array)
> @files, %refs, $refs
жесть.
Последний блок вообще нечитабелен, Возможно, если вы 6 лет пишете на 1 языке, то вам это привычно (за 6 лет легко можно научиться читать даже машинный код, я знаю, что люди раньше перфокарты умели читать без компьютера), но по моему это напрасная трата времени. Экономия от написания $1 вместо $match[1] например не стоит потери читабельности.
А еще в Перле абсолютно дурацкие и провоцирующие к ошибкам 2 контекста для переменных и извратный способ получения аргументво функции.
Все же что-то серьезное и крупное на нем писать нельзя. Даже один программист легко наворотит 100% нечитабельный скрипт, а что сделает команда (много человек, у каждого свой характер, свои привычки, помножьте это на поистине безграничные возможности обфускации кода в Перле), страшно представить.
> for my $f (@files)
Лишь бы не писать нормально, for ($var in $array)
> @files, %refs, $refs
жесть.
Последний блок вообще нечитабелен, Возможно, если вы 6 лет пишете на 1 языке, то вам это привычно (за 6 лет легко можно научиться читать даже машинный код, я знаю, что люди раньше перфокарты умели читать без компьютера), но по моему это напрасная трата времени. Экономия от написания $1 вместо $match[1] например не стоит потери читабельности.
А еще в Перле абсолютно дурацкие и провоцирующие к ошибкам 2 контекста для переменных и извратный способ получения аргументво функции.
Все же что-то серьезное и крупное на нем писать нельзя. Даже один программист легко наворотит 100% нечитабельный скрипт, а что сделает команда (много человек, у каждого свой характер, свои привычки, помножьте это на поистине безграничные возможности обфускации кода в Перле), страшно представить.
Будем считать, что вы не выспались. По Perl вам незачет.
1. Не надо мешать теплое с мягким, «плохость» кода и непонимание вами языка
2. Префиксы контекста переменных (и контексты скаляра) это как раз фишка перла, за которую я его очень люблю. И читать код, равно как ловить ошибки проще, поскольку сразу виден контекст.
3. $match[1] в модели strict вам сразу выкинет error, а за build-in переменные типа $MATCH, вам сразу настучит по голове тим лидер. Потому как, либо вы используете понятные тому, кто хоть 15 минут потратил на разбор регекспов в перл переменные ${digit}, либо используете //g, чтобы собрать поиск в массив. Зачем делать сложно то, что можно сделать просто
4. передача параметров и объявления классов в перл исторически не особо прозрачные, но шоподелать
5. использовать функцию там где можно написать простейший регексп… можно конечно, но если работаешь в команде — это пример скрипта для себя, опять же зачем делать сложно то что можно сделать просто
6. mail.ru, amazon.com (правда при масштабировании переписанный на другой приблуде)…
7. У любой Perl команды есть соглашение о коде. У нынешнего Perl'а высокий порог вхождения поэтому профи пишут более чем понятно… для других профи. Меня пхп-шники вымораживают больше, вот где аццкий ад, пару раз приходилось подчищать сопли… А казалось бы
1. Не надо мешать теплое с мягким, «плохость» кода и непонимание вами языка
2. Префиксы контекста переменных (и контексты скаляра) это как раз фишка перла, за которую я его очень люблю. И читать код, равно как ловить ошибки проще, поскольку сразу виден контекст.
3. $match[1] в модели strict вам сразу выкинет error, а за build-in переменные типа $MATCH, вам сразу настучит по голове тим лидер. Потому как, либо вы используете понятные тому, кто хоть 15 минут потратил на разбор регекспов в перл переменные ${digit}, либо используете //g, чтобы собрать поиск в массив. Зачем делать сложно то, что можно сделать просто
4. передача параметров и объявления классов в перл исторически не особо прозрачные, но шоподелать
5. использовать функцию там где можно написать простейший регексп… можно конечно, но если работаешь в команде — это пример скрипта для себя, опять же зачем делать сложно то что можно сделать просто
6. mail.ru, amazon.com (правда при масштабировании переписанный на другой приблуде)…
7. У любой Perl команды есть соглашение о коде. У нынешнего Perl'а высокий порог вхождения поэтому профи пишут более чем понятно… для других профи. Меня пхп-шники вымораживают больше, вот где аццкий ад, пару раз приходилось подчищать сопли… А казалось бы
Индусский код тихо курит в сторонке.
вот: The International Obfuscated C Code Contest www.ioccc.org/main.html
Не дал бы ни первое место, ни второе ни одному из вариантов кода в статье. Оба достаточно читаемы, понятны, и даже оформлены с отступами и разбиением на блоки, чего не скажешь о примерах из IOCCC в духе:
#include <stdio.h>
#include <math.h>
double l;main(_,o,O){return putchar((_--+22&&_+44&&main(_,-43,_),_&&o)?(main(-43,++o,O),((l=(o+21)/sqrt(3-O*22-O*O),l*l<4&&(fabs(((time(0)-607728)%2551443)/405859.-4.7+acos(l/2))<1.57))[" #"])):10);}
В чем смысл? Каковы критерии? Любой пример можно сделать ещё более неудобочитаемым.
Та ну, код вполне читается, даже я прочёл первый пример спокойно, при том что С\С++ явно не моя профессия. Второй пример вообще сущая простота
Да ну, обфусукатору сказать: друг, используй только вот эти символы 0,O,1,I,l,_
Это посильнее Фауста Гёте будет :)
Почему то вспомнился анедот:
Добавьте в широко используемый h file
#define TRUE FALSE /*happy debugging motherfucker!*/
Это посильнее Фауста Гёте будет :)
Почему то вспомнился анедот:
Добавьте в широко используемый h file
#define TRUE FALSE /*happy debugging motherfucker!*/
тока что погуглил. есть улучшение:
#define TRUE random()%2
#define TRUE random()%2
* This source code was highlighted with Source Code Highlighter.
На Хабре уже сто лет есть тег source…
Рядом с постом наверно только для меня сверкает «из песочницы»? Хорошо сказано!
Это означает, что вы сейчас не можете код отредактировать, чтобы избавить наши браузеры от буйства тегов :)? Или это означает, что в песочнице вообще недоступны ХабраТеги? Просто я довольно давно ей не пользовался.
Если вы про тег code, то я не видел подсветки, а так, могу специально для вас убрать «This code was highlighted....».
<source lang=cpp>, а не code
Тогда вынужден признать, что не знал об этом. В редакторе кнопка с надписью «code» вставляет тег code.
Хотя, есть тут кое-какие мысли… на счет
>>> Это означает, что вы сейчас не можете код отредактировать, чтобы избавить наши браузеры от буйства тегов :)?
Думаю неверное рассуждение, ведь по-любому в итоге получется «буйство тегов», чтобы мы могли увидеть подсветку, и это не зависит от того, использованы ли эти теги вами, или вставляются редактором, когда используется тег source.
Хотя, есть тут кое-какие мысли… на счет
>>> Это означает, что вы сейчас не можете код отредактировать, чтобы избавить наши браузеры от буйства тегов :)?
Думаю неверное рассуждение, ведь по-любому в итоге получется «буйство тегов», чтобы мы могли увидеть подсветку, и это не зависит от того, использованы ли эти теги вами, или вставляются редактором, когда используется тег source.
Почему вам кажется, что фраза «тег source» может означать тег code? У вас всё хорошо? Я за вас волнуюсь.
А почему с таким сарказмом? У вас что всех так встречают? За волнение спасибо, а вы мне пофигу, если что!
P. S. И карму оставьте в покое!
P. P. S. На счет кармы, может поможете мне опубликовать этот пост в «Кодобред»?
P. S. И карму оставьте в покое!
P. P. S. На счет кармы, может поможете мне опубликовать этот пост в «Кодобред»?
Сарказм — это не страшно, привыкайте. В данном случае его применение обосновано не вашим незнанием возможностей хабра (что простительно новичку), а неспособностью внимательно прочитать комментарий оппонента.
Что касается вашего топика, его полезность равна нулю, поэтому желание что-то делать с вашей кармой у меня отсутствует.
Что касается вашего топика, его полезность равна нулю, поэтому желание что-то делать с вашей кармой у меня отсутствует.
Что-то уже начинаю волноваться за вас. Вы твердите о невнимательном прочтении комментария оппонента, а мою почему-то читаете невнимательно. Вы сами поняли, что не знаю возможностей хабра, поэтому мой комментарий как раз к месту, я ведь хотел выяснить, что именно имел ввиду оппонент.
«Если вы про тег code, то я не видел подсветки...». Обратите внимание, там стоит «Если»!
«Если вы про тег code, то я не видел подсветки...». Обратите внимание, там стоит «Если»!
То, что изложено выше — это только цветочки. Вот как порой выглядят ягодки:
Код:
std::cin >> _ >> __ >> ___;
std::cin >> ____ >> _____;
int _0_ = ( _ + __ ) * (___ + static_cast(____) / static_cast(_____));
___000___ _________(_0_);
местами напоминает разъехавшийся смайлик
(\_/)
(O.o)
(> <)
/_|_\
Для всех, кто считает примеры не вполне удачными, неадекватно отобранными или и то и другое — в названии поста не использовано слово «Самый» вместо «Лучшего», вот поэтому примеры хорошо читаются, при этом неудобочитаемы!
а почему «Ненормальное Программирование»? Лучше бы это было в блоге «Кодобред», что ли :)
Гдето видал, полностью «задефайненный» русскими буквами исходник на С++. Тоесть типо
А по нормальному вот так:
Сейчас найти не смог, если кто знает киньте ссылку.
если ()
начало ....
конец иначе начало
.... конецА по нормальному вот так:
if ()
{
...
} else {
...
}
Сейчас найти не смог, если кто знает киньте ссылку.
Это я когда-то писал, вот: habrahabr.ru/blogs/crazydev/72627/
Ну и еще мое же: habrahabr.ru/blogs/crazydev/73963/
Ну и еще мое же: habrahabr.ru/blogs/crazydev/73963/
НЛО прилетело и опубликовало эту надпись здесь
А еще есть классные варианты даже на томже PHP, когда в скрите куча переменных типа:
$0O0O0O, $O000O00 и так далее…
$0O0O0O, $O000O00 и так далее…
bool result = false;
…
// some code
…
if (result.ToString() < 5 ) {
}
…
// some code
…
if (result.ToString() < 5 ) {
}
Немножко java:
class $<_, $, $_> {$ _;<_> $($ _){}<$> $($ _,$ $_){_=$_;}}
Код, который занял 2-ое место очень порадовал.
Частенько человечеству приходят гениальные (и к тому же элементарные) мысли, взглянув на которые каждый думает: «Блин, это же так элементарно, как я до такого не додумался!».
Частенько человечеству приходят гениальные (и к тому же элементарные) мысли, взглянув на которые каждый думает: «Блин, это же так элементарно, как я до такого не додумался!».
НЛО прилетело и опубликовало эту надпись здесь
Вполне себе читаемо )
Не понимаю, как это сложнее, чем:
¯\_(ツ)_/¯
class DataServiceContractDispatcher
{
DataServiceContractDispatcher(int dataServiceContractFactoryHandle)
...
¯\_(ツ)_/¯
function illiiil(iilli,illlii){
return iilli*illlii;
}
var iili{
this.iillili = 1;
this.iillli = function(){return this.iillili++;}
this.illi=function(iilll){
var iillili=this.iillili*2;
return illiiil(iillili,this.iillili);
}
}
var illl=iili();
illl.illi(1);
return iilli*illlii;
}
var iili{
this.iillili = 1;
this.iillli = function(){return this.iillili++;}
this.illi=function(iilll){
var iillili=this.iillili*2;
return illiiil(iillili,this.iillili);
}
}
var illl=iili();
illl.illi(1);
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Лучший неудобочитаемый код