Код должен быть коротким/кратким? [закрытый]

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

Код должен быть коротким, конкретным и сосредоточенным. Вы всегда можете многословно объяснить свои идеи в комментариях .

Корреляция между кратким кодом и производительностью не обязательно. Это миф. В зрелых языках, таких как C / C ++, компиляторы способны очень эффективно оптимизировать код. В таких языках есть причина предполагать, что чем более сжатый код, тем лучше работает. В более новых, менее оптимизированных для производительности языках, таких как Ruby, отсутствуют функции оптимизации компилятора, присущие компиляторам C / C ++, но по-прежнему нет оснований полагать, что сжатый код лучше работает. Реальность такова, что мы никогда не знаем, насколько хорошо код будет работать в производственной среде, пока он не попадет в производство и не профилирован. Простой, безобидный, функции могут быть огромными узкими местами производительности, если вызываются из достаточного количества мест в коде. В системах с высокой степенью параллелизма самые большие узкие места обычно возникают из-за плохих алгоритмов параллелизма или чрезмерной блокировки. Эти проблемы редко решаются путем написания «краткого» кода.

Суть в следующем: код, который работает плохо, всегда можно отредактировать, если профилирование определит, что это узкое место. Эффективный рефакторинг кода возможен только в том случае, если его легко понять. Код, который написан, чтобы быть «кратким» или «умным», часто бывает труднее рефакторировать и поддерживать.

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

Мои два цента ...

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

Суть в следующем: код, который работает плохо, всегда можно отредактировать, если профилирование определит, что это узкое место. Эффективный рефакторинг кода возможен только в том случае, если его легко понять. Код, который написан, чтобы быть «кратким» или «умным», часто бывает труднее рефакторировать и поддерживать.

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

Мои два цента ...

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

Суть в следующем: код, который работает плохо, всегда можно отредактировать, если профилирование определит, что это узкое место. Эффективный рефакторинг кода возможен только в том случае, если его легко понять. Код, который написан, чтобы быть «кратким» или «умным», часто бывает труднее рефакторировать и поддерживать.

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

Мои два цента ...

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

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

Мои два цента ...

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

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

Мои два цента ...

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

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

На мой взгляд, есть пара моментов, которые определяют, когда следует прекратить оптимизацию:

• Стоит тратить время на оптимизацию. Если у вас есть люди, которые проводят недели и ничего не находят, можно ли лучше использовать эти ресурсы?

• Каков порядок приоритетов оптимизации. Когда дело доходит до кода, нужно учитывать несколько различных факторов: время выполнения, пространство для выполнения (как запущенный, так и только скомпилированный код), масштабируемость, стабильность, количество реализованных функций и т. Д. Частично это торговля вне времени и пространства, но это также может быть то, где идет некоторый код, например, может ли промежуточное ПО выполнять специальные команды SQL или они должны маршрутизироваться через хранимые процедуры для повышения производительности?

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

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

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

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

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

В отличие от длинного / бессвязного? Конечно!

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

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

Когда это не удается ... конечно, оставьте мне комментарий.

И не говорите мне «что» в комментарии (это то, для чего предназначен код), скажите мне «почему».

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

Например, изменение

for (int i = 0; i < n; i++)
    foo[i] = ...

на

int * p = foo, q = foo+n;
while ( *p++ = ... < q );

является примером сокращения силы, которое, кажется, экономит шаги, но не учитывает факт что foo является массивом, что затрудняет чтение.

Другой распространенный метод - использование bool вместо enum.

enum {
    MouseDown,
    MouseUp
};

Если this be

bool IsMouseDown;

, не учитывается тот факт, что это конечный автомат, что усложняет код для поддержания.

Итак, мое практическое правило было бы в вашей реализации не копаться на более низкий уровень, чем концепции, которые вы пытаетесь выразить.

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

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

. Люди не являются компиляторами. Составители могут съесть этот материал и продолжить движение. Непонятный код мысленно воспринимается людьми не так быстро, как ясно понятый код.

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

Кроме того, комментарии должны только дополнение и не должно описывать ваш код, ваш код должен описывать сам себя. Если вам нужно прокомментировать строку, потому что она не Очевидно, что сделано, это плохо. Большинству опытных программистов требуется больше времени для чтения объяснения на английском языке, чем для чтения самого кода. Я думаю, что книга Code Complete забивает этот дом.

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

Here's a good article by Steve McConnell - Best Practices http://www.stevemcconnell.com/ieeesoftware/bp06.htm

I think short/concise are two results from well written code. There are many aspects to make code good and many results from well written code, realize the two are different. You don't plan for a small foot print, you plan for a function that is concise and does a single thing extremely well - this SHOULD lead to a small foot print (but may not). Here's a short list of what I would focus on when writing code:

• single focused functions - a function should do only one thing, a simple delivery, multi featured functions are buggy and not easily reusable
• loosely coupled - don't reach out from inside one function to global data and don't rely heavily on other functions
• precise naming - use meaningful precise variable names, cryptic names are just that
• keep the code simple and not complex - don't over use language specific technical wow's, good for impressing others, difficult to easily understand and maintain - if you do add something 'special' comment it so at least people can appreciate it prior to cursing you out
• evenly comment - to many comments will be ignored and outdated to few have no meaning
• formatting - take pride in how the code looks, properly indented code helps
• work with the mind of a code maintenance person - think what it would be like to maintain the code you're writting
• do be afraid or to lazy to refactor - nothing is perfect the first time, clean up your own mess

Да. Всегда.

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

Что касается имен объектов, то представление об этом претерпело эволюцию с появлением новых языков программирования.

Если взять языки с фигурными скобками, начиная с C Краткость считалась душой остроумия. Итак, у вас будет переменная для хранения значения ссуды, например, с именем «lv». Идея заключалась в том, что вы набираете много кода, поэтому сводите нажатия клавиш к минимуму.

Затем появилась санкционированная Microsoft «Венгерская нотация», где первые буквы имени переменной должны были указывать на ее базовый тип. . Можно использовать «fLV» или что-то подобное, чтобы указать, что стоимость ссуды была представлена ​​переменной с плавающей запятой.

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

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

У меня был профессор информатики, который сказал: «Как инженеры, мы постоянно работаем. создавая типы вещей, которых никогда раньше не было. Имена, которые мы им даем, останутся, поэтому мы должны быть осторожны, давая вещам осмысленные имена ».

Поскольку больше нет необходимости вводить полное имя, вы можете использовать столько символов, сколько необходимо для описания.

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

У меня был профессор информатики, который сказал: «Как инженеры, мы постоянно работаем. создавая типы вещей, которых никогда раньше не было. Имена, которые мы им даем, останутся, поэтому мы должны быть осторожны, давая вещам осмысленные имена ».

Поскольку больше нет необходимости вводить полное имя, вы можете использовать столько символов, сколько необходимо для описания.

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

У меня был профессор информатики, который сказал: «Как инженеры, мы постоянно работаем. создавая типы вещей, которых никогда раньше не было. Имена, которые мы им даем, останутся, поэтому мы должны быть осторожны, давая вещам осмысленные имена ».

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

У меня был профессор информатики, который сказал: «Как инженеры, мы постоянно работаем. создавая типы вещей, которых никогда раньше не было. Имена, которые мы им даем, останутся, поэтому мы должны быть осторожны, давая вещам осмысленные имена ».

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

У меня был профессор информатики, который сказал: «Как инженеры, мы постоянно работаем. создавая типы вещей, которых никогда раньше не было. Имена, которые мы им даем, останутся, поэтому мы должны быть осторожны, давая вещам осмысленные имена ».