Кого волнует ... пока результат в порядке?

Question

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

Итак, вопрос скорее в риторическом опросе: когда можно игнорировать семантику написанного? Где граница?

• оператор ++ (постфикс / префикс)
• string.empty () против string == ""
• vector.empty () против vector.size () == 0
• перечислить {вкл, выкл} против логического вкл = истина; выкл = ложь
• ...

Назовите это.

РЕДАКТИРОВАТЬ -

Я не хотел задавать вопрос о необходимости (микро) -оптимизации. Скорее, мне нужны мнения о том, насколько хорошо вы должны быть осведомленными о том, что вы пишете, и о таких высказываниях, как "но в любом случае это сводится к мечу, так зачем мне делать это перечислением?" (это крайний случай ...).

Answer 1

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

Вот ваш ответ: до тех пор, пока вы сможете понять код, и это не помешает вам поддерживать его.

Answer 2

Я написал много кода в моей карьере. Конечно, не так много, как здесь, но тем не менее, много кода. За это время я узнал одну вещь, которая снова и снова подтверждается: когда вы становитесь неряшливыми, когда игнорируете детали, появляются дефекты.

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

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

Answer 3

"когда разрешено игнорировать семантику написанного? Где граница?"

Я думаю, что разумный вопрос звучит так: «когда должен игнорировать семантику того, что пишет?»

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

Answer 4

Зависит от вашей функции стоимости

Здесь есть пара измерений, о которых люди любят спорить и часто смешивают. На самом деле ответ - это зависит. Что вы действительно цените?

• Количество символов
• Количество созданных операций
• Run-время
• Портативность
• ремонтопригодность
• Ясность
• Одаренность
• Стабильность (без ошибок?)
• Расширяемость

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

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

Answer 5

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

Но создание перечисления для логического значения просто неправильно.

Answer 6

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

Answer 7

Наблюдая за примерами, которые вы предоставили - Следующее:

operator++ (постфикс / префикс)

string.empty() против string == ""

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

В отличие от следующих примеров:

vector.empty() против vector.size() == 0

enum erate {on, off} против boolean on=true; off=false

Совершенно разумно.

vector.empty() предпочтительнее, если контекст его использования предназначен только для определения, является ли вектор пустым. На риск звучит снисходительно (что я делаю не намерен быть): это сводится к здравому смыслу. Зачем спрашивать размер вектора, если вы хотите знать только, если он пуст? Это все равно, что спросить кого-то, сколько денег у него в кошельке, когда вы просто хотите узнать, достаточно ли у него денег на колу.

Что касается enum erate {on, off} против boolean on=true; off=false, спросите себя: насколько вероятно, что вы сможете добавить еще одно значение к перечислению в будущем? Кажется разумным, что кто-то может захотеть enum erate {on, off, indeterminate} `(или некоторый вариант), поэтому ответ может быть да. В противном случае достаточно простого логического значения.

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

Answer 8

Микро оптимизация бессмысленна в 99% случаев. Например, если ваш компилятор интернирует все "" в один экземпляр в любом случае, вы никоим образом не увеличиваете производительность, используя String.Empty. Отсутствие какого-либо измеримого эффекта обычно является лучшим, на что вы можете надеяться, я видел, как «оптимизации» снижают производительность из-за того, что компилятор делает лучшую работу, а оптимизация мешает ему.

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

Answer 9

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

Answer 10

Граница побочных эффектов.

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

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