Должны ли мы нанять кого-то, кто пишет C на 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;
 }

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

Это не ужасно идиоматический 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 =~ /^([^,]*)(?:,|$)/;

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

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

#!/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 в оригинале. Исходная версия больше, чем она должна быть по какой-то причине. И я не ушел с пути, чтобы уменьшить этот код до минимума.

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

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

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

• Он не использовал use strict
• Он не включал предупреждения.
• Он использует старую версию с двумя аргументами open.
• Комментарий "open file" повреждает и создает впечатление, что код, который он обычно пишет, не содержит комментариев.
• Код трудно поддерживать
• Был ли он разрешен использовать модули CPAN? Хороший программист Perl сначала посмотрел бы на эту опцию.

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

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

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

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

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

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

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

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

Единственный дисквалифицирующий комментарий может быть "Я всегда программирую Perl таким образом. Я не понимаю этого регулярного выражения".

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

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

Итак, это не аренда.

Это работает? Он написал это в приемлемый период времени? Считаете ли вы его поддерживаемым?

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

Я бы сказал, что его код является адекватным решением. Это работает, не так ли? И есть преимущество в ремонтопригодности, написав "longhand", а не как несколько символов кода, как вы можете.

Девизом Perl является " Там больше, чем один способ сделать это." Perl на самом деле не разбирается в стиле кодирования, как это делают некоторые языки (мне тоже нравится Python, но вы должны признать, что люди могут получить вид снобизма при оценке того, является ли код "pythonic" или нет).

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

Вопрос в том, могут ли они учиться? Есть так много, чтобы искать в кандидате, прошедшем этот кусок кода.

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

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

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

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

#!/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;

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

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

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

Но он работает...

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

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

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

Я не обязательно говорю, что весь синтаксический анализ должен представлять собой огромное количество нечитаемых регулярных выражений CSV, таких как ("([^"]*|"{2})*"(,|$))|"[^"]*"(,|$)|[^,]+(,|$)|(,) или одно из многих похожих регулярных выражений, но, по крайней мере, для прохождения строк или вместо использования substring().

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

Если бы мы смотрели на более сложную/большую часть кода, я бы сказал, что комментарии нужны. Но для that (особенно так, как это было написано - хорошо написано), я так не думаю.

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

Решающим моментом здесь является, естественно, после того, как он работает так, как ожидалось, независимо от того, поддерживается ли код.

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

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

Затем, возможно, вам захочется научить его регулярным выражениям, но только внимательно: -)

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

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

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

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

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

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

Я видел, что 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";    
}