Мы должны нанять кого-то, кто пишет C в Perl? [закрытый]

Как не Perl (? Программист?), Я должен сказать, что это, вероятно, самый разборчивый Perl, который я когда-либо читал! :)

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

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

Может возникнуть очевидный вопрос: если вы вообще не используете Perl в своей компании, имеет ли значение , насколько хорош его код Perl?

Я не уверен, что элегантность его кода Perl многое говорит о его навыках на том языке, который вы фактически используете.

Может быть, попросить его написать больше версий того же кода? Если сомневаетесь в приеме на работу, задавайте кандидату дополнительные вопросы.

The fact that he hasn't used a single piece of regex in the code should make you ask him a lot of questions about why he did write like that.

Maybe he's Jamie Zawinski or a fan and he didn't want to have more problems?

I'm not necessarily saying that the whole parsing should be a huge amount of unreadable CSV parsing regex like ("([^"]*|"{2})*"(,|$))|"[^"]*"(,|$)|[^,]+(,|$)|(,) or one of the many similar regex around, but at least to traverse the lines or instead of using substring().

Только начальный блок указывает на то, что он пропустил основы Perl.

    while ($line ne "") {
    # Skip spaces and start with empty field.

    if (substr ($line,0,1) eq " ") {
        $line = substr ($line,1);
        next;
    }

Это должно быть, по крайней мере, написано с использованием регулярного выражения для удаления начальных пробелов. Мне нравится ответ jrockway best , модули потрясающие. Хотя я бы использовал для этого регулярные выражения, например.

#!/usr/bin/perl -w
#
# $Id$
#

use strict;

open(FD, "< qq.in") || die "Failed to open file.";
while (my $line = <FD>) {
    # Don't like chomp.
    $line =~ s/(\r|\n)//g;
    # ".*?[^\\\\]"  = Match everything between quotations that doesn't end with
    # an escaped quotation, match lazy so we will match the shortest possible.
    # [^",]*?       = Match strings that doesn't have any quotations.
    # If we combine the two above we can match strings that contains quotations
    # anywhere in the string (or doesn't contain quotations at all).
    # Put them together and match lazy again so we can match white-spaces
    # and don't include them in the result.
    my $match_field = '\s*((".*?[^\\\\]"|[^",]*?)*)\s*';
    if (not $line =~ /^$match_field,$match_field,$match_field,$match_field$/) {
        die "Invalid line: $line";
    }
    # Put values in nice variables so we don't have to deal with cryptic $N
    # (and can use $1 in replace).
    my ($user_id, $name, $level, $numeric_id) = ($1, $3, $5, $7);
    print "$line\n";
    for my $field ($user_id, $name, $level, $numeric_id) {
        # If the field starts with a quotation,
        # strip everything after the first unescaped quotation.
        $field =~ s/^"(.*?[^\\\\])".*/$1/g;
        # Now fix all escaped variables (not only quotations).
        $field =~ s/\\(.)/$1/g;
        print "   [$field]\n";
    }
}
close FD;

I wouldn't accept the candidate. He or she isn't comfortable with Perl's idioms, which will result in suboptimal code, less work efficieny (all those unnecessary lines have to be written!) and a inablilty to read code written by an experienced Perl coder (who of course uses regexes etc. at large).

But it works...

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

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

Простите этого парня. Я бы не осмелился анализировать CSV с помощью регулярного выражения, даже если это возможно.

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

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

Если этот человек думает, что у него очень хороший опыт работы с Perl, и он пишет Perl вот так, он, вероятно, стал жертвой эффекта Даннинга-Крюгера .

Итак, это не наем .

Я бы сказал, что его код - подходящее решение. Это работает, не так ли? А удобство сопровождения дает преимущество написания «от руки» вместо того, чтобы использовать как можно меньше символов кода.

Девиз Perl: « Есть более чем один способ сделать это ». Perl, в отличие от некоторых языков, действительно не подходит для вашего случая по поводу стиля кодирования (мне тоже нравится Python, но вы должны признать, что люди могут проявлять некоторый снобизм, оценивая, является ли код «питоническим» или нет).

Работает? Он написал это в приемлемый период времени? Как вы думаете, его можно обслуживать?

Если вы ответите мне на эти три вопроса, вы сможете пройти через мост смерти ( * ).

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

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

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

Единственным дисквалифицирующим комментарием может быть: «Я всегда программирую Perl таким образом. Я не понимаю, что такое регулярное выражение».

Я должен (в некотором роде) не согласиться с большинством высказанных здесь мнений.

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

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

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

РЕДАКТИРОВАТЬ Еще раз взглянув на код, я должен быть более решительным: хотя код выглядит очень чистым, на самом деле он ужасен . Сожалею. Это не Perl. Вы знаете поговорку «можно программировать Фортран на любом языке»? Да, ты можешь. Но не стоит.

Меня не волнует, использовал он регулярные выражения или нет. Меня также не волнует, выглядит ли его Perl как C или нет. Вопрос, который действительно имеет значение: хороший ли это Perl? И я бы сказал, что нет:

1. Он не использовал use strict
2. Он не включал предупреждения.
3. Он использует старомодную версию open с двумя аргументами.
4. Комментарий «открытый файл» причиняет мне боль, и у меня создается впечатление, что код, который он обычно пишет, не содержит никаких комментариев.
5. Код трудно поддерживать
6. Разрешено ли ему использовать модули CPAN? Хороший программист на Perl сначала рассмотрит этот вариант.

Не использовать строгие предупреждения / использовать предупреждения, систематическое использование substr вместо регулярного выражения, отсутствие использования модулей. Это определенно не тот, кто имеет « очень хороший опыт работы с Perl ». По крайней мере, не для реальных проектов Perl. Как и вы, я подозреваю, что это, вероятно, программист на языке C с базовыми знаниями Perl.

Это не означает, что они не могут учиться, тем более что вокруг есть другие люди, занимающиеся Perl. Однако это, кажется, означает, что они завысили свою квалификацию для работы. Уместно задать еще несколько вопросов о том, как именно они приобрели этот очень хороший опыт Perl .

Я бы сказал, что написание C на Perl - намного лучшая ситуация, чем написание Perl на C.Как часто упоминается в подкастах SO, понимание C - это достоинство, которое не все разработчики (даже некоторые хорошие) есть сейчас. Возьмите их на работу и купите для них копию Perl Best Practices , и все будет готово. После передового опыта скопируйте Промежуточный Perl , и они могут работать.

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

 #!/usr/bin/env perl

 use strict;
 use warnings;

 use Text::CSV;

 my $parser = Text::CSV->new({
     allow_whitespace   => 1,
     escape_char        => '\\',
     allow_loose_quotes => 1,
 });

 while(my $line = <>){
     $parser->parse($line) or die "Parse error: ". $parser->error_diag;
     my @row = $parser->fields;
     print $line;
     print "\t[$_]\n" for @row;
 }

Это не ужасно идиоматический Perl, но и не совсем ужасный Perl (хотя мог бы быть намного компактнее).

Два предупреждающих звонка - в строке shebang нет включите ' -w ' и нет ни ' use strict; ', ни ' use warnings; '. Это Perl в очень старом стиле; хороший код Perl использует как предупреждения, так и строгие.

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

Немного удивительнее неиспользование регулярных выражений. Например:

# Process every field in line.
while ($line ne "") {
    # Skip spaces and start with empty field.

    if (substr ($line,0,1) eq " ") {
        $line = substr ($line,1);
        next;
    }

Это можно было бы записать:

while ($line ne "") {
    $line =~ s/^\s+//;

Это обрезает все начальные пробелы с помощью регулярного выражения, не заставляя код повторяться по циклу. Значительная часть остального кода также выиграет от тщательно написанных регулярных выражений. Это типичная идиома Perl; удивительно видеть, что они не используются.

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

Рабочий код имеет значение. Более или менее идиоматический код лучше.

Также, конечно, есть модули Text :: CSV и Text :: CSV_XS, которые можно использовать для обработки CSV-синтаксического анализа. Было бы интересно узнать, знают ли они о модулях Perl.

Также существует несколько обозначений для обработки кавычек в цитируемых полях. Похоже, что код предполагает, что уместна обратная косая черта; Я считаю, что в Excel используются удвоенные кавычки:

"He said, ""Don't do it"", but they didn't listen"

Этому может соответствовать:

$line =~ /^"([^"]|"")*"/;

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

Поле без кавычек будет соответствовать:

$line =~ /^([^,]*)(?:,|$)/;

Это намного короче, чем показанные цикл и подстрока.

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

#!/usr/bin/perl -w

use strict;

open (IN, "qq.in") || die "Cannot open qq.in";

while (my $line = <IN>) {
    chomp $line;
    print "$line\n";

    while ($line ne "") {
        $line =~ s/^\s+//;
        my $field = "";
        if ($line =~ m/^"((?:[^"]|\\.)*)"([^,]*)(?:,|$)/) {
            # Quoted field
            $field = "$1$2";
            $line = substr($line, length($field)+2);
            $field =~ s/""/"/g;
        }
        elsif ($line =~ m/^([^,]*)(?:,|$)/) {
            # Unquoted field
            $field = "$1";
            $line = substr($line, length($field));
        }
        else {
            print "WTF?? ($line)\n";
        }
        $line =~ s/^,//;
        print "   [$field]\n";
    }
}
close (IN);

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

Поле без кавычек будет соответствовать:

$line =~ /^([^,]*)(?:,|$)/;

Это намного короче, чем показанные цикл и подстрока.

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

#!/usr/bin/perl -w

use strict;

open (IN, "qq.in") || die "Cannot open qq.in";

while (my $line = <IN>) {
    chomp $line;
    print "$line\n";

    while ($line ne "") {
        $line =~ s/^\s+//;
        my $field = "";
        if ($line =~ m/^"((?:[^"]|\\.)*)"([^,]*)(?:,|$)/) {
            # Quoted field
            $field = "$1$2";
            $line = substr($line, length($field)+2);
            $field =~ s/""/"/g;
        }
        elsif ($line =~ m/^([^,]*)(?:,|$)/) {
            # Unquoted field
            $field = "$1";
            $line = substr($line, length($field));
        }
        else {
            print "WTF?? ($line)\n";
        }
        $line =~ s/^,//;
        print "   [$field]\n";
    }
}
close (IN);

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

Поле без кавычек будет соответствовать:

$line =~ /^([^,]*)(?:,|$)/;

Это намного короче, чем показанные цикл и подстрока.

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

#!/usr/bin/perl -w

use strict;

open (IN, "qq.in") || die "Cannot open qq.in";

while (my $line = <IN>) {
    chomp $line;
    print "$line\n";

    while ($line ne "") {
        $line =~ s/^\s+//;
        my $field = "";
        if ($line =~ m/^"((?:[^"]|\\.)*)"([^,]*)(?:,|$)/) {
            # Quoted field
            $field = "$1$2";
            $line = substr($line, length($field)+2);
            $field =~ s/""/"/g;
        }
        elsif ($line =~ m/^([^,]*)(?:,|$)/) {
            # Unquoted field
            $field = "$1";
            $line = substr($line, length($field));
        }
        else {
            print "WTF?? ($line)\n";
        }
        $line =~ s/^,//;
        print "   [$field]\n";
    }
}
close (IN);

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

#!/usr/bin/perl -w

use strict;

open (IN, "qq.in") || die "Cannot open qq.in";

while (my $line = <IN>) {
    chomp $line;
    print "$line\n";

    while ($line ne "") {
        $line =~ s/^\s+//;
        my $field = "";
        if ($line =~ m/^"((?:[^"]|\\.)*)"([^,]*)(?:,|$)/) {
            # Quoted field
            $field = "$1$2";
            $line = substr($line, length($field)+2);
            $field =~ s/""/"/g;
        }
        elsif ($line =~ m/^([^,]*)(?:,|$)/) {
            # Unquoted field
            $field = "$1";
            $line = substr($line, length($field));
        }
        else {
            print "WTF?? ($line)\n";
        }
        $line =~ s/^,//;
        print "   [$field]\n";
    }
}
close (IN);

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

#!/usr/bin/perl -w

use strict;

open (IN, "qq.in") || die "Cannot open qq.in";

while (my $line = <IN>) {
    chomp $line;
    print "$line\n";

    while ($line ne "") {
        $line =~ s/^\s+//;
        my $field = "";
        if ($line =~ m/^"((?:[^"]|\\.)*)"([^,]*)(?:,|$)/) {
            # Quoted field
            $field = "$1$2";
            $line = substr($line, length($field)+2);
            $field =~ s/""/"/g;
        }
        elsif ($line =~ m/^([^,]*)(?:,|$)/) {
            # Unquoted field
            $field = "$1";
            $line = substr($line, length($field));
        }
        else {
            print "WTF?? ($line)\n";
        }
        $line =~ s/^,//;
        print "   [$field]\n";
    }
}
close (IN);

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

Хм, я не вижу в запросе ничего, что следует удалить кавычки и слова. Во входном файле было слово «мусор», а в выходном файле его нет.

Я видел CSV-файлы, экспортированные с кавычками, ожидали возврата тех же кавычек. Если бы ваша спецификация заключалась в удалении кавычек и посторонних слов после кавычек, возможно, эта работа потребовалась бы.

Я бы посмотрел на это и на многословие. Поищите кого-нибудь более ленивого (комплимент на Perl).

open (IN, "csv.csv");
while (<IN>) {
    #print $_;
    chomp;
    @array = split(/,/,$_);
    print "[User Id] =  $array[0]  [Name] = $array[1]  [Level] =  $array[2] [Numeric ID] = $array[3]\n";    
}

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

• Поняли ли вы ?
• Вы бы чувствовали себя комфортно, исправляя в нем ошибку?

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

С другой стороны, вы можете научить его регулярным выражениям, но только осторожно: -)

Не только код предполагает, что кандидат на самом деле не знает Perl, но и все те строки, которые говорят $ line = substr ($ line, 1) , ужасны на любом языке. Попробуйте разобрать длинную строку (скажем, несколько тысяч полей), используя такой подход, и вы поймете, почему. Это просто показывает, какого рода проблему обсуждал Джоэл Спольски в этой публикации .