Префиксы переменных

Венгерка и вариации - дерьмо и не нужны.

$ - скаляр

@ - массив

% - хэш

& - подпрограмма

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

Да ну, надо писать так?

У кого есть свои стандарты по префиксам

ИМХО это не только не нужно, но и вредно.

И да, индекс может быть в одном месте кода счётчиком и не быть индексом, а в другом месте быть индексом, и не быть счётчиком, а вот имя-то одно. Или предлагаешь на ходу переименовывать?

Да ну, надо писать так?

так тоже не нужно.

Поддерживаю и первого и второго оратора. И не забываем, что префикс '_' зарезервирован, по этому в двойне.

Или предлагаешь на ходу переименовывать?

Для начала неплохо «стандартизировать» стандартные структуры (а точнее ссылки на них). Конкретно: массив, хэш, ссылка на sub, ссылка на скаляр. Еще бы неплохо отделять чисто строковые скаляры. И также бывает нужно на сложные структуры (массив хэшей, хэш хэшей и т.п.).

Твой пример взят с потолка. У меня обычно индексы определяются либо в for (my $i = 0; ...), либо один, максимум для два в одной фукнции. Потому что в циклах правильно выделять отдельную переменную для вложенных структур.

В перле не зарезервирован.

Для начала неплохо «стандартизировать» стандартные структуры

в C/C++ не нужно, ибо там компилятору наплевать, кто как крякает и хрюкает. Он просто не скомпилирует присваивание свиньи к утке. А во всяких php/perl'ах оно конечно можно... Но эту проблему префиксами не решить, если нет строгой типизации, то её нет.

Твой пример взят с потолка.

та не. Из RL.

У меня обычно индексы определяются либо в for (my $i = 0; ...)

ну тут это счётчик и не индекс, а в цикле индекс но не счётчик. Как ты его назовёшь?

Потому что в циклах правильно выделять отдельную переменную для вложенных структур.

это как?

ну тут это счётчик и не индекс, а в цикле индекс но не счётчик. Как ты его назовёшь?

Сейчас у меня просто $index, $cnt :) И вообще, ты легко подменяешь понятия.

это как?

my @retval;

my @abook = (
{  Name => 'drBatty',
   Phones => {
     Home => '123',
     Work => '345'
   }
},
);

foreach my $record (@abook) {
   my $phones = $record->{Phones}; # <-- HERE

   for my $phone (values %$phones) {
      &check($phone) or die "invalid phone number";
      push @retval, $phone;
   }
}

Как-то так, написал наобум. Принцип в том, что сложные структуры в циклах, типа $hash->[$index]{$supername}{$subname} приводят к тормозам. А также просто нечитабельно и создают киллометровые строки.

Следовательно, создание индексов/счетчиков нужно производить внутри или снаружи, один раз, для одной/двух целевых структур. При этом имена внутри играют меньшую роль. И вообще, я не просил придумывать префиксы для индексов :)

Сейчас у меня просто $index, $cnt :)

ну и хорошо.

И вообще, ты легко подменяешь понятия.

это не я, а авторы разнообразных венгерок. За типами должен компилятор следить, а скрипты на perl'е нужно применять только для несложных задач, в которых $index'а достаточно(т.е. если задача действительно настолько сложна что индексы становяться счётчиками или ещё чем-то, и если у тебя возникает потребность в «хрюкающей утке», то есть смысл подумать о более мощном ЯП).

my $phones = $record->{Phones}; # <-- HERE

для этого существует такая штука, которая называется СУБД. Вот, науглил для тебя: http://2lx.ru/2009/04/working-with-sqlite-in-perl/ Зачем тебе придумывать свой велосипед?

Принцип в том, что сложные структуры в циклах, типа $hash->[$index]{$supername}{$subname} приводят к тормозам. А также просто нечитабельно и создают киллометровые строки.

угу.

то есть смысл подумать о более мощном ЯП

Перл итак достаточно мощен для ряда задач.

для этого существует такая штука, которая называется СУБД

Не решает это ничего. Структура в моем примере может быть составлена из выборки БД. Конечно, это не самый оптимальный путь, т.к. код уж слишком простой.

Вот, науглил для тебя

Спасибо, но это уже освоено и я пишу более продвинутый код.

Перл итак достаточно мощен для ряда задач.

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

Не решает это ничего. Структура в моем примере может быть составлена из выборки БД. Конечно, это не самый оптимальный путь, т.к. код уж слишком простой.

Если это выборка из БД, то твоя структура является всего-лишь обёрткой, это другое совсем.

Спасибо, но это уже освоено и я пишу более продвинутый код.

ну ладно. Хотя я всё равно предпочитаю юзать чужие велосипеды.

Так есть универсальный стандарт про венгерскую нотацию: «Не нужна».

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

Использую 'm' для членов класса(int mCount), 'p' для указателей(pValue), иногда могу ещё использовать 'b' для булевских переменных, хотя редко, все функции с большой буквы, имена переменных с маленькой(верблюжатина). Подчёркивания стараюсь не использовать. Чистый венгерский стиль имхо перегружен, хотя особо не напрягает, лишь бы имена переменных были понятны и код нормально написан, чтобы в нём разобраться. Остальное по барабану )

Разве не легче для определения типа переменной использовать её название? $article, скорее всего, окажется объектом, а не индексом массива, а %handles - хэшем временных файловых дескрипторов, а не количеств чего-то.

скорее всего

Непрофессионально.

Read «Perl best practice», read «Code complete». И в той и в другой книге есть по главе посвященной именованию переменных.

И да, твои префиксы вредны.

Разве не легче для определения типа переменной использовать её название?

Нет. Ниже пример, как ты поймешь какая структура где используется?

sub countArticles {
   my ($articles) = @_;

   my $count = 0;

   for (@$articles) { # what is type of $_ ? ehm....
      $count++;
   }
}

sub countAuthors {
   my ($articles) = @_;

   my %authors;  

  for my $article (@$articles) {
     # aha! $article is hash ref!
     $authors{$article->{author}}++;
  }

  return scalar keys %authors;
}

$article, скорее всего, окажется объектом, а не индексом массива, а %handles - хэшем временных файловых дескрипторов, а не количеств чего-то.

Это хорошо, что у вас такие простые структуры. Также вы, наверное, считаете, что разыменовывание это слишком дорогая операция и поэтому когда в функцию передается список аргументов из 1_000_000 в виде списка вы не замечаете, хотя знаете что так не положено:

my @artciles = getArticles();

&dosomething(@articles);

my $count = countArticles(@articles); # array of 1_000_000 elements...

sub countArticles {
  my (@articles) = @_; # you've increased memory usage twice just for '@'
  ...
}

У меня очень размашистый стиль. В этом примере важна каждая запятая и кавычка - каждый символ на своем месте и соответствует моему стилю.

Имя хэша - всегда единственное число. Имя массива - множественное.

use Carp qw( confess );

my @retvals;

my @abooks = (
    {
        Name => 'drBatty',
        Phone => {
            Home => '123',
            Work => '345',
        },
    },
);

for my $each_record_hr ( @abooks ) {
    my $phones_hr = $each_record_hr->{'Phone'};

    for my $each_phone ( values %{ $phones_hr } ) {
        check( $each_phone ) or confess 'invalid phone number';
        push @retvals, $each_phone;
    }
}

Я нигде не говорил, что передавать большие количества объектов в массивах через стек аргументов - это хорошо. Ссылка на массив, естественно, будет гораздо лучше.

Ниже пример, как ты поймешь какая структура где используется?

for my $article (@$articles) {
# aha! $article is hash ref!

Префиксы тут всё равно ничем не помогут, имя переменной задаётся рядом с потенциально неправильным её использованием. Или Вы предлагаете переименовать $articles? Тогда и countAuthors придётся переименовать, чтобы показать, что она принимает только ссылки на массивы хэшей.

А как тогда именовать сложные многоэтажные структуры данных - по типу каждого из их этажей? Вроде my $ahhhs_data = [ { { { a => 1 } } } ];. Тогда уж проще воспользоваться Data::Diver/Data::DPath.

Исходя из здравого смысла, чем вообще может быть $article? Скаляром - текстом (статьи/записи/чего-то ещё)? Тогда бы мы не считали авторов. Массивом? Это было бы странно (зачем нумерованные внутренности там, где их можно и нужно идентифицировать текстовыми строками?). Остаётся хэш.

Ещё один вариант - объект, и тогда нам вовсе не нужно беспокоиться о типе.

Хотя назвать назвать переменную $ah_articles и точно знать, что это Array of Hashes, тоже было можно, мне кажется, что без этого можно обойтись.

У кого есть свои стандарты по префиксам

Для приватных методов класса/объекта использую подчеркивание ('_'). Доступ к свойствам класса/объекта через префиксы 'get_' и 'set_'.

Perl best practice

ОФигеть: списки во множественном числе, хэши - в единственном. Плюс добавлять _ref для ссылок. Как назвать хэшреф содержащий списки статей? $article_ref ? Логично, что скорей всего там хэшреф на одну единственную статью, нежели соглашение по «бест практиклес». А если реально одна статья и тоже $article_ref ? Вообщем, надо еще смотреть на имя функции, которое может быть не совсем адекватным. Т.е. еще и описалово функции надо читать. И хорошо если описалово будет написано. И я считаю использование суффикса _ref излишним, когда итак понятно (из функции), что возвращаемый тип явно не скаляр.

$arcticles = getArcticles();
$articleCount = countArticles();

Code complete

Тут намного лучше все описано. Однако, специфика перла упущена и не раскрыта :-(

Тогда и countAuthors придётся переименовать, чтобы показать, что она принимает только ссылки на массивы хэшей.

Да. Внутри функции как вы предложили:

my ($ah_articles) = @_;

Вроде my $ahhhs_data = [ { { { a => 1 } } } ];

Почему бы нет?

Тогда уж проще воспользоваться Data::Diver/Data::DPath.

И получить вагон тормозов. Спасибо, это решение в 10 раз хуже.

Спасибо. Возьмем на заметку. А почему суффиксы, а не префиксы?

«Code complete» — Тут намного лучше все описано. Однако, специфика перла упущена и не раскрыта :-(

Да, как фундамент, — нужно опираться на нее. Вторая книга это лучшее, что я видел по аккуратному написанию кода на perl, но она очень далека от идела, слишком много чего в ней мутного.

Как назвать хэшреф содержащий списки статей?

Если хеш по именам, то:

$lists_of_articles_by_name

И я считаю использование суффикса _ref

Придерживаюсь того же мнения, ибо и так понятно, что $lists_of_articles_by_name это ссылка, а не @ и не %.

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

$list_of_articles_by_name

А не слишком муторно писать столько букв? Или у тебя редактор с autocomplete? Я этой функцией не пользуюсь просто.

Ну, оптимальная длина переменной (code complete) около 14 символов. Так что не слишком муторно. Perl очень выразительный язык, поэтому можно тратить чуть больше времени на написание переменных. Autocomplete есть, но не активный — я им пользуюсь (жму на клавишу), только если забыл переменную.

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

для перла так и не сделали IDE, которая бы цветом указывала типы?

для перла так и не сделали IDE, которая бы цветом указывала типы?

Давно уже: emacs-PDE

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