Вредные и полезные привычки при написаний AutoIt-кода

[Kalisnik]

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

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

 

[alex33]

CreatoR <
Вот мои:
полезные: 1, 2, 5, 7, 8, 10, 11, 12, 13, 16, 18.
и вредные: 1, 3, 4, 5, 6, 7.

 

[Belfigor]

Моя вредная привычка заключается в том, что комментарии в коде присутствуют в размере в несколько раз превышающим сам код. То есть строка из 20 символов, может спокойно содержать комментарий из 300-500 символов.
То есть как-то так:

#cs - Обратиться сюда командой ConCheck("Cargo Hold") - если мы хотим различить заполненность трюма по одному из трех состояний Full, Empty, Not Empty
#ce - Обратиться сюда командой ConCheck("Cargo Hold", "%") - если мы хотим узнать процентное значение заполненности трюма 0-100%
Local $CargoBarStatus = PixelSearch($CargoBar[0], $CargoBar[1], $CargoBar[2], $CargoBar[3], $CargoBar[4], $CargoBar[5]) ;Проверяем есть ли чо в трюме
If @error Then ;Цвет не нашли - значит трюм заполнен на 100% (Верно лишь тогда когда окно трюма находится на правильной позиции) (При необходимости надо прикрутить проверку наличия окна, и возврат его текущих координат или же возврат окна на эталонные координаты)
   If $ToCheck3 = "%" Then Return 100 ;Если $ToCheck2 = "%" (Запрос был сформирован как ConCheck("Cargo Hold", "%") вернуть 100%
   Return "Full" ;Вернуть Full
Else ;Если трюм не полный
   If $CargoBarStatus[0] = $CargoBar[0] Then ;Если трюм пустой
	  If $ToCheck3 = "%" Then Return 0 ;Вернуть 0%
	  Return "Empty" ;Если $ToCheck2 <> "%" - Вернуть Empty
   Else ;Финальная проверка если трюм не пустой и не полный. Вернуть текущее процентное значение состояния заполненности трюма. Расчет идет по формуле: Округлить результат((([Координата места где заканчивается индикатор заполненности-Координата левого края] - [Координата правого края области поиска-Координата левого края области поиска] * 100 ), 0)
	  If $ToCheck3 = "%" Then Return Round(($CargoBarStatus[0] - $CargoBar[0])/($CargoBar[2]-$CargoBar[0])*100, 0) ;Если $ToCheck2 = "%" (Запрос был сформирован как ConCheck("Cargo Hold", "%") - расчитать текущее % значение заполненности трюма и вернуть его в формате [Число]%

 

[madmasles]

Belfigor [?]

Моя вредная привычка заключается в том, что комментарии в коде присутствуют в размере в несколько раз превышающим сам код.

ИМХО, это у Вас весьма полезная привычка.

 

[kaster]

madmasles [?]

ИМХО, это у Вас весьма полезная привычка.

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

 

[AZJIO]

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

2+2 ; складываем два числа

это излишнее, потому что явно понятно и без комментариев.
-------------------------
1. Я перестал присваивать переменным пустую строку. Оказалось что переменная и элементы массива по умолчанию являются строковый тип и дополнительно ничего не требуется.
2. Стал пользоваться Tidy постоянно. Поставил его на клавишу Alt+Z и любой код новичка обязательно пропускаю через Tidy, перед тем как разбираться в нём.
3. Стал делать план перед любым проектом и отчёт о выполненных пунктах. Это позволяет на этапе зарождения программы учесть всё что будет включено заранее и избавляет от дальнейшего дописывание заплаток.
4. Любой участок кода, который можно сделать в виде отдельной самостоятельной функции, так и делаю. Это позволяет забыть об очистке переменных и не следить чтобы такое дублирование приводило к растрате памяти. Кстати про ООП дочитал статью, в которой как раз и говорилось что при переходе Firefox на ООП привело к тому что некоторые классы держали в памяти дубликаты переменных и при закачке файла 1 Гб размер в памяти был дублированным.

Из недостатков:
1. Редко пользуюсь Au3Check.exe. Во первых он замедляет работу при тестировании программы заставляя объявить все переменные для кода который возможно через минуту будет удалён. Но для UDF обязательно проверяю, чтобы исключить необъявленные переменные (это уже не недостаток).
2. До сих пор не использую #Region

-----------------------------
На счёт сложения битовых флагов с помощью BitOR (например стилей GUI). Заявил об этом на офсайте, в принципе все приняли это как рекомендацию, а не как жёсткое правило, потому что те, кто понимают что это такое, они либо складывают с помощью BitOR, либо заранее уверены, что складываемые константы являются одиночными флагами.

 

[max1300]

вот когда я пишу скрипт чтоб придумать имя переменной я особо сильно не напрягаюсь

 

[C2H5OH]

Я между строками кода привык ставить пустую строку. Мне так легче код читать...

 

[MEXAH]

Избегаю ставить пробелы в коде, и мне это нравится. ;D
Увлекаюсь рутиной, написав 50 условий в конце понимаю что можно было их все вписать в 1 цикл.

 

[Александр_]

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

 

[alex33]

Избегаю ставить пробелы в коде, и мне это нравится. ;D

Да, :D Я этим тоже бывает страдаю

 

[AZJIO]

Избегаю ставить пробелы в коде, и мне это нравится. ;D

Да, :D Я этим тоже бывает страдаю

А смысл их ставить? Есть этап набора кода есть этап чтения, между этими этапами запускаешь Tidy и он всё поставит куда надо и читать становиться удобно.
Кстати в Python'е есть правила для каждого элемента кода, это как знание русского языка, писать можешь сленгом но не каждый поймёт, а напишешь правильно и интерпретируется однозначно и понятно. Вот статья

 

[qqww22]

Избегаю ставить пробелы в коде, и мне это нравится. ;D

Да, :D Я этим тоже бывает страдаю

А смысл их ставить? Есть этап набора кода есть этап чтения, между этими этапами запускаешь Tidy и он всё поставит куда надо и читать становиться удобно.
Кстати в Python'е есть правила для каждого элемента кода, это как знание русского языка, писать можешь сленгом но не каждый поймёт, а напишешь правильно и интерпретируется однозначно и понятно. Вот статья

Мы не ищем лёгких путей анархия :IL_AutoIt_1:

 

[alex33]

AZJIO [?]

А смысл их ставить? Есть этап набора кода есть этап чтения, между этими этапами запускаешь Tidy и он всё поставит куда надо и читать становиться удобно.

Ну да, я так и делаю, сначала пишу код, потом запускаю эту штуку и всё.

 

[weweWe45s]

9. Иногда хожу по комнате...

Я думал я один такой :laugh:

а у меня турник & кольца есть (дома и на работе) вот

 

[passwd]

Скажу я вам это наоборот отличная привычка. CreatoR, перенесите этот пункт в полезные привычки =)
Во время ходьбы думается лучше и креативнее, чем во время сидения.

 

[landrail]

Вредные или хорошие, да у меня по моему все вредные)
1. Пытаюсь делать программы много функциональными
2. Как что-нибудь новое узнаю сразу прикручиваю к том что уже делаю...
3. Редко довожу проекты до конца(Очень редко, если цель поставлю ток)
4. Пишу код не акуратно, другие не могут понять где-что, а я быстро нахожу. И хоть не акуратно пишу, зато работает)
5. Переменные на бум, с ними не заморачиваюсь
6. Использую tidy
7. После мелких или больших изменений врубаю скрипт и любуюсь, несколько раз врубаю...
8. Когда не за компом формулирую мысли в мозгах как можно примерно сднлать...
9. Иногда хожу по комнате...
10. Храню настройки в ini, через ресстр мудно...
11. пытаюсь делать что-то интерестное, и для себя, только вот потом у меня программы качают... И не могут разобратся)
12. Гуй делаю через коду...
вроде все =)

7."После мелких или больших изменений врубаю скрипт и любуюсь, несколько раз врубаю...". )) Гладить код - это гладить себя.