Как программно отличить плод ПРОФЕССИОНАЛА от плода ДИЛЕТАНТА? - страница 7

 

Все строковые функции являются затратными. 

Все функции работы с графикой являются затратными.

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

Самая трудоемкая здесь будет WinowsRedraw() и Сomment() - так как при ее вызове тоже перерисовывается график.

что то так, на первый взгляд.

 

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

Дальше уже неинтересно.

 
Mathemat:

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

Дальше уже неинтересно.

Как я представляю, профессиональный программист должен писать для себя, как писатель или композитор, и на заказ, тоже также профессионально, обязательно с реальным положительным результатом. Другое дело, если его просят написать по задуманной заказчиком идее (ТЗ), несмотря на то, что его идея неубедительна для программиста, в этом случае программист предупреждает, что с этим советником вряд ли заказчик заработает, но заказчик настаивает и программист выполняет заказ. Я понимаю, что тут другая специфика, что никакой шедевр тут не выдержит испытанием временем, но согласитесь, что есть примеры долгожительства (проверено на тестере) в маркете на МТ5 на всей истории. Думаю, что это будет точкой отсчёта для определения профессиональности программы и программиста, как и трейдера не потому, что он знает, умеет, а по результату. Конечно, эта профессиональная работа должна стоить соответственно. И халтурки посшибать никому не возбраняется, как часто делают и писатели, и композиторы, снисходительно относясь к этому, как к вынужденной подработке "для поддержки штанов". Извините за откровенность, а без неё зачем высказываться!

 
Не продается вдохновенье. Но, можно рукопись продать.
 

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

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

Фишка
Баллы
Использование массивов
+1
Повторное использование кода (отношение количества функций к количеству строк кода)
+4
Операторы += -= /=
+1
Операторы % >> <<
+3
Рекурсивный вызов функций
+5
Использование директив препроцессора
+3
Количество закомментированных строк к количеству кода
+5
Использование "медленных" функций
-3
Использование однотипных переменных типа: time1, time2, time3, time4
-4

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

 

Ребят, единственный способ отличить код профи от кода новичка - это наличие результатов оптимизации кода. Вы не сможете отследить стопроцентную оптимизацию. Сможете отследить лишь некоторые её элементы. А частичную оптимизацию может и новичок выполнить. Например, заменить операцию "умножения на два" операцией "сложения величины с самой собой". Бросьте вы это - идея отслеживания слишком рессурсозатратна по сравнению с результатом, который может дать. Не выгодно так вкладываться в прогу - это попытка выстрогать спичку из бревна  - одна спичка как изделие, а остальное стружка.

 
drknn:

Ребят, единственный способ отличить код профи от кода новичка - это наличие результатов оптимизации кода.

Галимое гонево ))
 

Признаки профессионального кода:
Смыслоёмкие имена переменных и функций;
Хорошо просматриваемая структура программы;
Наличие толковых комментариев.

ЗЫ Искать такие признаки в программе можно только вручную. Автоматизация не прокатит.

ЗЫЫ Это всё нужно искать в программах, написанных программистом для себя.
На сторону такой код в наше жлобское время уважающий себя программист не отдаст. 

 
FAQ:

Все строковые функции являются затратными. 

Все функции работы с графикой являются затратными.

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

Самая трудоемкая здесь будет WinowsRedraw() и Сomment() - так как при ее вызове тоже перерисовывается график.

что то так, на первый взгляд.


Интересен вопрос ускорения оптимизаций (тестирование - отдельный вопрос) и уменьшение
потребляемой памяти. На форуме кто-то вскользь упомянул что нужно предотвращать "добавление" графических
объектов во время оптимизации. По идее, оптимизация вообще графику не видит и я предполагал что такие
команды как ObjectCreate() просто игнорируются во время оптимизации.
Нужно их блокировать или нет?
А если их все-таки надо блокировать, значит придется каждый раз добавлять проверку
if(IsOptimization()==false ) {
}
При этом, сами такие проверки также влияют на скорость оптимизации.
Являются ли затратными функции проверки состояния?
Имеет ли смысл присваивать их переменным и в дальнейшем использовать переменные?
У меня практически всегда есть Сomment() - его тоже следует блокировать во время оптимизации?
Как быть с Alert и Print? (опять же - во время оптимизации). Они же не пишутся в лог во время оптимизации?
 
chief2000:

А если их все-таки надо блокировать, значит придется каждый раз добавлять проверку

Только не

if(IsOptimization()==false ) {
}

а

if( !IsOptimization() ) {
}

Но лучше так:

if ( !IsOptimization() && ( !IsTesting() || IsVisualMode() ) ) {

// ...

}

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

PS.

А вообще, что вы так оживились? Топикстартер периодически указывает, что вы ..., а от Д'Артаньян.