LINUX.ORG.RU

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

 ,


0

2

У кого есть свои стандарты по префиксам, как указано здесь, но для Perl? Для Ъ (c++):

  • '_' = member of a class
  • 'c' = a count of something
  • 'd' = a difference between two things (i.e. an offset)
  • 's' = a data sample
  • 'f' = a boolean flag
  • 'p' = a pointer
  • 'h' = a handle to a system resource
  • 'rg' = a range (i.e. an array)
  • 'ix' = an index

Пример использования:

void CFilter::Run(void) {
    SStageInfo *pStageInfo = _rgStageInfo;

    if (_fDownConverting) pStageInfo->DownConvert(_centerFrequency, _cChans);

    while ( (pStageInfo != &_rgStageInfo[_cStages]) && 
            pStageInfo->CalculateResultPairForNextStage(_cChans) ) {
        ++pStageInfo;
    }

    if ( pStageInfo == &_rgStageInfo[_cStages] ) {
        if ( _csHoldoff ) {
            _csHoldoff--;
        } else if (_fDownConverting) {
            CFft::EdmaTriggerAll(_mid, pStageInfo->GetBuffer(), 
                                 _rgixFirOutput, _fDownConverting);
        } else {
            // Reset EDMA source address to simulate 
            // a FIFO source to a larger sink buffer.
            EdmaSetSrc(_hEdmaFirOut, pStageInfo->GetBuffer());
            EdmaSetChannel(_hEdmaFirOut);
        }
    }
}

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

anonymous ()

$ - скаляр

@ - массив

% - хэш

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

anonymous ()
Ответ на: комментарий от anonymous

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

gh0stwizard ★★★★★ ()

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

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

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

drBatty ★★ ()

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

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 1)
Ответ на: комментарий от drBatty

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

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

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

gh0stwizard ★★★★★ ()
Ответ на: комментарий от gh0stwizard

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

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

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

та не. Из RL.

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

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

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

это как?

drBatty ★★ ()
Ответ на: комментарий от drBatty

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

Сейчас у меня просто $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} приводят к тормозам. А также просто нечитабельно и создают киллометровые строки.

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

gh0stwizard ★★★★★ ()
Последнее исправление: gh0stwizard (всего исправлений: 1)
Ответ на: комментарий от gh0stwizard

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

ну и хорошо.

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

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

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

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

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

угу.

drBatty ★★ ()
Ответ на: комментарий от drBatty

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

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

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

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

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

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

gh0stwizard ★★★★★ ()
Ответ на: комментарий от gh0stwizard

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

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

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

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

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

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

drBatty ★★ ()

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

kovrik ★★★★★ ()

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

anonymous ()

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

xterro ★★★★★ ()
Последнее исправление: xterro (всего исправлений: 2)

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

AITap ★★★★★ ()

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

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

soomrack ★★★ ()
Ответ на: комментарий от AITap

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

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

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 '@'
  ...
}

gh0stwizard ★★★★★ ()
Ответ на: комментарий от gh0stwizard

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

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

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;
    }
}
outtaspace ★★★ ()
Последнее исправление: outtaspace (всего исправлений: 1)
Ответ на: комментарий от gh0stwizard

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

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

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, тоже было можно, мне кажется, что без этого можно обойтись.

AITap ★★★★★ ()

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

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

outtaspace ★★★ ()
Ответ на: комментарий от soomrack

Perl best practice

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

$arcticles = getArcticles();
$articleCount = countArticles();
Все итак понятно, что $articleCount это скаляр и какое-то число. А вот с $arcticles ситуация, как я описал выше. Может и список, может и хэш.

Code complete

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

gh0stwizard ★★★★★ ()
Ответ на: комментарий от AITap

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

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

my ($ah_articles) = @_;

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

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

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

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

gh0stwizard ★★★★★ ()
Ответ на: комментарий от outtaspace

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

gh0stwizard ★★★★★ ()
Ответ на: комментарий от gh0stwizard

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

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

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

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

$lists_of_articles_by_name

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

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

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

soomrack ★★★ ()
Последнее исправление: soomrack (всего исправлений: 2)
Ответ на: комментарий от soomrack

$list_of_articles_by_name

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

gh0stwizard ★★★★★ ()
Ответ на: комментарий от gh0stwizard

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

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

soomrack ★★★ ()

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

stevejobs ★★★☆☆ ()
Ответ на: комментарий от stevejobs

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

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

soomrack ★★★ ()

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

redgremlin ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.