[Закрываются] устаревшие методы кодирования

Случайная защита присвоения:

Помещение lvalue на правой стороне не нужно на некоторых более новых языках как C#.

В C# следующее не скомпилирует:

if (variable = 0)

Таким образом в C# нет никакой потребности сделать:

if (0 == variable)

Эта практика является очень обычной в программах C/C++ для предотвращения случайных присвоений, которые были предназначены, чтобы быть сравнениями.

Несколько точек возврата:

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

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

Отказ от ответственности: Существуют все еще серьезные основания минимизировать несколько точек возврата, и иногда полезно иметь только один.

Заголовочные файлы

На наиболее современных языках Вы не разделяете свой код на объявление и определение.

C++ определяет для нескольких, заголовочный файл включает

В C++ Вы раньше часто делали:

#ifdef _MYFILE_H_
#define _MYFILE_H_

//code here

#endif

Это иногда приводило бы к чему-то как следующее хотя:

#ifdef _MYFILE_H_
#define _WRONGNAME_H_

//code here

#endif

Лучший способ сделать это, если Ваш компилятор поддерживает его:

#pragma once

C объявления переменной

С C необходимо было объявить все переменные наверху блока кода. Еще более поздние версии C не потребовали этого, хотя, но люди все еще делают это.

Венгерская запись: (Читайте, содержит некоторую уникальную информацию),

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

Прежде чем было очень важно в C иметь вещи как:

int iX = 5;
char szX[1024];
strcpy(szX, "5");

Поскольку у Вас мог быть полностью тип небезопасные функции как:

printf("%i", iX);

Теперь, если бы я назвал бы строку x, моя программа отказала бы.

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

Но тем не менее это - хорошая идея, как обсуждено Joel в его смысле.

Короткие идентификаторы: многие олдскульные кодеры используют короткие, загадочные идентификаторы. Краткость является полезным достоинством, но полагая, что хороший IDE имеет автоматическое заполнение, описательное имя намного лучше, чем что-то легкое для ввода.

Я раньше разделял все мои номера строки 10, запуская каждую логически отдельную часть кода с промежутками в 100 или 1000 т.е.

10 Print "Hello"
20 Gosub 100
30 'Peeks and Pokes

По очевидным причинам я больше не кодирую как это.

Выравнивание в столбцах (например, переменные в объявлениях или = в присвоениях).

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

Короткие строки: Некоторые люди настаивают на 80 текстах столбца. Остальная часть нас имеет реальные мониторы и не возражает, если строка является дольше, чем 80 символами. Это может улучшить удобочитаемость, чтобы иметь более длинные строки.

Хотя это находится в Java, это - книга, которую я рекомендую для людей, которые хотят оптимизировать/модернизировать их стиль кодирования: http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091

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

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

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

Как он был сказан прежде, не пытайтесь адаптировать идиомы одного языка к другому. Это особенно верно на решительно различных языках, таково как движение от C++ до Python. Также (это могло бы просто быть вопросом персонального стиля), я раньше объявлял переменную, затем присваивал ей значение позже. Я нахожу это намного быстрее и эффективным пространством, чтобы просто объявить и определить его одновременно.

С современными продвижениями в платформах и IDE, там некоторые методы кодирования, которые действительно больше не применяются и другие, которые могут быть просто неправыми теперь

Зависит от языка в большой степени.

W.r.t C:

• Используя register ключевое слово

W.r.t C++:

• Злоупотребление static; теперь Вы, как предполагается, используете namespaces, даже если анонимные

Или, я неправильно понимал Ваш вопрос?

Руководство касательно подсчета указателя является старой практикой, которая сводит меня с ума абсолютно. Я исправляю приблизительно 1-2 ошибки в месяц, потому что кто-то пытался быть умным и вручную касательно количества указатель. Просто используйте интеллектуальный указатель. Это сэкономит Вам время.

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

Рассмотрите тело функции, которое содержит:

//some code
if(something)
{
   var c = 123;
}

alert(c); // gives 123 when the if is executed and undefined when it doesn't.

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

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