Устаревшие методы кодирования

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

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

Другой - венгерская нотация. Я ненавижу, что все мои переменные, связанные с определенным объектом, разбросаны по всей моей intellisense.

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

Ответ 1

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

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

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

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

Ответ 2

Защита от случайного распределения:

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

В С# следующее не будет компилироваться:

if (variable = 0)

Итак, в С# нет необходимости делать:

if (0 == variable)

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

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

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

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

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

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

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

С++ определяет для нескольких файлов заголовков

В С++, который вы часто делали:

#ifdef _MYFILE_H_
#define _MYFILE_H_

//code here

#endif

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

#ifdef _MYFILE_H_
#define _WRONGNAME_H_

//code here

#endif

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

#pragma once

Объявления переменных

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

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

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

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

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

Потому что вы можете полностью набрать небезопасные функции, например:

printf("%i", iX);

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

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

Но все же это хорошая идея, о которой говорил Джоэл в его смысле.

Ответ 3

Я использовал для разделения всех номеров строк на 10, начиная каждый логически отдельный фрагмент кода с интервалами 100 или 1000.

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

Ответ 10

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

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

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

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

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

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

Ответ 11

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

В значительной степени зависит от языка.

W.r.t C:

Использование ключевого слова register

W.r.t С++:

Нарушение static; теперь вы должны использовать namespace, даже если анонимные

Или я не понял ваш вопрос?

Ответ 12

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