Распространенная ситуация при программинге, как быть? Быстродействие vs Лаконичность - страница 4

 
lob32371:

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

На самом деле решение было предложено до замечательного ответа Pavlick - макросы. Тогда ни о каких входных параметрах даже речь вести не нужно.

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

 
C-4:

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

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

Да и сами разработчики вовсю используют макросы.

 
lob32371:

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

Да и сами разработчики вовсю используют макросы.

Рассуждать без решения реальных задач сложно. К тому же на холивар легко нарваться. Многое зависит от конкретной школы программирования. Я вот например из мира C#/Java и управляемого кода. Я не использую макросы, массивы и структуры вообще. Вместо этого опираюсь на стандартную библиотеку.
 

О лаконичности и оптимальности.

Когда из 10 тысяч строк кода сделал 2 тысячи с небольшим, то скорость работы советника не уменьшилась (код не мой).  Может просто стало проще вносить изменения немного. Хотя тот код (оптимизированный) уже вырос до 15 тысяч строк. На первый этап оптимизации ушло две недели, за второй даже браться не собираюсь, потребуется несколько месяцев. 

 
C-4:
Рассуждать без решения реальных задач сложно. К тому же на холивар легко нарваться. Многое зависит от конкретной школы программирования. Я вот например из мира C#/Java и управляемого кода. Я не использую макросы, массивы и структуры вообще. Вместо этого опираюсь на стандартную библиотеку.

Наверное, это не на MQL.

Vinin:

О лаконичности и оптимальности.

Когда из 10 тысяч строк кода сделал 2 тысячи с небольшим, то скорость работы советника не уменьшилась (код не мой).  Может просто стало проще вносить изменения немного. Хотя тот код (оптимизированный) уже вырос до 15 тысяч строк. На первый этап оптимизации ушло две недели, за второй даже браться не собираюсь, потребуется несколько месяцев. 

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

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

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

Вот чего не научился, так это комментариями сопровождать код. Всю архитектуру держу в голове.

 
lob32371:

Наверное, это не на MQL.

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

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

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

Вот чего не научился, так это комментариями сопровождать код. Всю архитектуру держу в голове.

 

По собственному опыту. Комментарии нужны. В студенчестве ( а закончил 25 лет назад институт) делал работу. Занимала около 100-120 распечатанных листов (листинг). Сколько там было строк. Уже и не упомню.

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

 
Vinin:
Оффтоп: Вы, как модератор, даете добро?
 
lob32371:

Вот чего не научился, так это комментариями сопровождать код. Всю архитектуру держу в голове. 

Код должен быть самодокументируемым. Комментарии - зло. Их нужно использовать очень ограничено. 
 
lob32371:
Оффтоп: Вы, как модератор, даете добро?

Добро на что?

Код должен быть коротким и ясным. Если нет возможности для ясного кода, то комментарии обязательны. Я пишу функции на 5-10 строк. Хотя некоторые больше, но занимает не больше экрана. Разобраться что и как она делает  несложно - для меня комментарии не нужны. 

Но если у Вас функция будет занимать 1000-2000 строк, то Вам без комментариев не обойтись 

 
C-4:
Код должен быть самодокументируемым. Комментарии - зло. Их нужно использовать очень ограничено. 
Да, имена переменных, функций, типов, классов, структур и т.д. говорят о себе очень многое. Не возьмусь утверждать выделенное. Иногда бывают ситуации, когда прокомментировать прямым текстом требуется.
Причина обращения: