Я не могу знать, что «R» позже в коде. Кроме того, имена переменных - это одно, но вы должны комментировать код для многолетнего объяснения. NB: Это, вероятно, должно быть сообщество Wiki, поскольку нет определенного ответа.

Я понятия не имею, как вы можете отслеживать вещи, когда у вас есть имена переменных.

Вообще, намного лучше, чтобы иметь более длинные имена, которые фактически описывают переменные. То, что нужно стремиться к кому-либо, чтобы кто мог читать код и понять, что происходит, чтобы иметь возможность понять, что они для etc =)

Вот несколько полезных учебных пособий для более подробной информации:

http://durak.org/sean/pubs/software/cvsbook/The-commitinfo-And-loginfo-And-rcsinfo-Files.html
http://durak.org/sean/pubs/software/cvsbook/The-verifymsg-And-rcsinfo-Files.html#The-verifymsg-And-rcsinfo-Files

Вы не можете делать то, что хотите, только с одним крючком, но вы можете использовать два крючка, commitinfo позволит вам проверить сами файлы и verifymsg позволит вам проверить сообщение. Оба могут использоваться для отмены фиксации (программы должны просто выйти со статусом 1). Если вы не знали, контрольный список , commitinfo и «verifymsg» можно найти в каталоге CVSROOT репозитория. Я бы рекомендовал поместить любые сценарии, которые вы пишете как крючки, в этот каталог, но это не имеет значения, так как вы получаете указать полный путь. Кроме того, perl не является необходимым или обязательным, просто для меня, чтобы написать некоторые (глупые) примеры в:

checkoutlist

# these files will be automatically checked out for you
acceptable

verifymsg

# specifies which file to run as hook, %l is filename of log message
# bar$     /path/to/repo/CVSROOT/verify_ends_in_bar %l
DEFAULT    /path/to/repo/CVSROOT/acceptable %l %s

приемлемый

#/usr/bin/perl -w

use strict;
use warnings;

# this would be simpler if cvs passed sane arguments
my ($logfile, $dir, @files) = @ARGV;
my $grep = `grep -i 'accept liability' $logfile`;
exit 0 if $grep;

my $found = 0;
foreach my $file (@files) {
    my $path = join '/', $dir, $file;
    die "Can't find file $path" if ! -e $path;
    my $grep = `grep -i 'evidence of any deliberation' $path`;
    $found++ if $grep;
}
die "You must accept liability or show evidence of deliberation" if $found < @files;

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

Отредактируйте еще раз , я только что понял, что я изначально был не прав, и вы можете передать и файл журнала, и зафиксированные имена файлов в verifymsg сделать ответ немного проще.

Проверьте работу Эдварда Тафте и особенно эту книгу

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

Кстати, мне нравится его техника визуализации сверкающих данных. Сюрприз! Google уже написал его и выложил на Код Google

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

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

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

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

Просто чтобы закрыть этот вопрос: я перезапустил устройство, и это помогло.

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

Код не является плохим, но пропуск 80 символов является битовым произвольным, и переменная ошибки не является необходимой, если выполняется проверка с помощью цикла (и должна быть bool , если она сохранена). Вы можете поместить чтение из cin непосредственно в , если , что, возможно, скорее является идиомой Perl.

Вот мой вариант:

int taxableIncome;

for (;;) {
    cout << "Please enter in your taxable income: ";
    if (cin >> taxableIncome) {
        break;
    } else {
        cout << "Please enter a valid integer" << endl;
        cin.clear();
        cin.ignore(numeric_limits<streamsize>::max(), '\n');
    }
}

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

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

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

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

Напишите код для чтения. Хорошее правило - это тем больше, чем имеет объем, в котором используется переменная, тем более описательным его именем должно быть. Параметры функции Особенно должны иметь очень описательные имена, за исключением функций, в которых это очевидно, что делает параметр, как в
двойной SQRT (Double N)

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

//these are okay
var sb = new StringBuilder();
var sw = new StringWriter();
var cmd = new SqlCommand();
for(var i = 0; i< count; i++) {}

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

О единственном времени, когда я использую короткие имена переменного переменной, либо если короткое имя полностью описательно (т. Е. X & Y в ситуации, посвященной координатам), либо это функция утилиты, которая работает на типе данных (т. Е. Первая буква этой строки. Это строка, что еще вы можете сказать об этом? Я назвал это s.)

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

Использование имен коротких переменной для локальных переменных в порядке, пока объем ограничен.

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

using (StreamReader sr = new StreamReader(inputStream))
{
    sr.ReadByte();
} 

в отличие от:

using (StreamReader streamReader = new StreamReader(inputStream))
{
    streamReader.ReadByte();
} 

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

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

Примечание: только потому, что использование переменной ограничено в его объеме, не обязательно означает, что бессмысленное имя в порядке. Если есть хорошее имя, которое представляет то, что делает объект, то его следует использовать. Если вы можете придумать имя переменной, которая отвечает «Почему?», То это имя намного предпочтительнее.

Также, используя « I и« J для для индексов хорошо понимается разработчиками. По соглашению переменные счетчика петли были названы таким образом со времен Fortran.

for (int i = 0; i < 10; i++)
{
    for (int j = 0; j < 10; j++)
    {
        PerformOperation(i,j);
    }
}

Я бы считал это плохой стиль кодирования? Ну да.

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

Есть несколько исключений, где я думаю, что имена коротких переменных в порядке:

индексы (в основном для петлей), такие как:

for (int i = 0; i < 10; i++)
{
}

переменные, используемые в очень ограниченном объеме, такие как запросы Linq, лямбда или Некоторые из примеров уже упоминались, такие как Streamwriters и -Readers, и такие являются еще одним примером, где я думаю, что имена коротких переменных в порядке.

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

Это плохо. Это ненаправлено.

Короткие переменные имеют свое место. На самом деле нет причин писать для (INT итератор; итератор

Решеновое правило: одна буква на экран досягаемости. С резервными 24 линиями экрана.

Исключение составляют одну-две чрезвычайно часто используемые глобал или полуоблинно, такие как указатель на хранилище данных или указатель входных данных, и делает их длиной 1-3 букв. Но все остальное - использовать причину. Короткие петли - одно письмо. Местные жители функции - 3-5 букв. Переменные классов - полное слово. Библиотечные классы / имена функций - два слова.

Несколько лет назад я обнаружил, что произойдет, если я сделаю свой функции короткие :

• Я мог бы понять их. Мой мозг маленький, а длинные функции не подходят.

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

• Количество переменных в функции (или классе) мало. Вспоминание, которое из того, что из времени объявления в использовании времени легко, потому что расстояние короткое .

• Число в моих функциях в моих функциях мало, поэтому мне не нужно выяснить, какие переменные идут где.

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

Поскольку количество переменных в объеме мало, и цель очевидно, я редко нужно прилагать любые усилия, чтобы выбрать описательное имя. Поскольку я не хочу напрягать мой маленький мозг больше, чем я должен, Я никогда не сокращаюсь . Мое имя по умолчанию для переменной - это имя типа. Например. Класс Foo идет в переменной foo . В моем коде, если это когда-либо что-то другое, вы знаете, что-то особенное происходит, и вы должны обратить внимание.

В старые времена моя привычка No-abbbruviation будет производить громоздкий код, но поскольку мои методы и классы невелики, код не страдает.

• Ни один MyISAM не имеет общего кэша данных. Это задокументировано в описании "key_buffer_size" из официальной документации : Это потому, что MySQL полагается на операционную систему для выполнения кэширования файловой системы для чтения данных, поэтому вы должны оставить некоторое место для кэша файловой системы.

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

• Так что ответьте на ваш второй вопрос: никогда.

Важно не попадать в "избыточный размер буфера" также для различных переменных myisam, таких как read_buffer_size, read_rnd_buffer_size, sort_buffer_size, join_buffer_size и т.д., так как некоторые динамически распределяются, так что больше не всегда означает быстрее - и иногда это может быть даже медленнее - смотрите этот пост в mysqlperformanceblog для очень интересного случая.

Если вы находитесь в 5,1 на платформе posix, вы можете провести сравнительный тест myisam _ использовать _ mmap на вашей рабочей нагрузке, это должно помочь высоким конфликтам, уменьшив количество вызовов malloc ().

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

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

Я не вижу причин использовать короткие имена переменных, которые ничего не говорят. Мы живем в 21 веке, у нас есть IDE с IntelliSense (или другое автозавершение)! Просто нажмите Ctrl + пробел, и это поможет вам обычное имя переменной в зависимости от типа переменной, например

StringBuilder <Ctrl+Space> stringBuilder;
List<Person> <Ctrl+Space> persons;

Это даже проще, чем ввести что-то вроде sb или другое короткое имя. Больше нет причин использовать короткие имена.

P.S.: Единственным исключением для меня являются счетчики, такие как i, j, k в цикле.