Вниманию участников! Данный форум теперь является архивом и вскором времени здесь нельзя будет создавать новых тем! Просьба всем для общения и создания новых тем перейти на наш новый форум: http://amxmodx.su/

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

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

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

Создаем макроконстанту, очевидно, определяющую абсолютный максимум клиентов - 32.

По следующей строке кода можно судить о многом:

• 1. Элемент "new" говорит о том, что мы "создаем" переменную.
  
• 2. Т.к. присвоения конкретного значения не происходит, значение переменной инициализируется как "ноль".
  
• 3. Т.к. после элемента "new" отсутствует атрибут "const", можно судить о том, что впоследствии переменная может изменять свое значение.
  
• 4. Префикс "g_", говорит нам о том, что переменная создается в глобальном пространстве, т.е. переменная является глобальной, т.о. будет доступна из любой части кода.
  
• 5. Используя квадратные скобки, мы задаем размерность, значит, это не просто одиночная переменная, а массив переменных, имеющий размерность 32 + 1 == 33 - таково общее количество элементов данного массива (от 0-ого элемента до 32-ого - всего 33).
  
• 6. Тэг Float говорит о том, что переменные массива являются дробными.
  
• 7. Т.к. впоследствии при использовании данного массива в коде тэг Float фигурировать уже не будет, к имени массива мы добавляем символ "f" (это один из примеров т.н. венгерской нотации, широко использующейся программистами всего мира), что в любой момент укажет нам на то, что данный массив имеет тип Float.
  
• 8. Теперь откинем все вспомогательные элементы языка на данной строке, а также префиксы венгерской нотации, и мы увидем основу имени "PlayerReloadEndGameTime", скорее всего, речь идет о игровом времени момента конца перезарядки, очевидно, оружия игрока.
  
• 9. Т.к. речь идет о массиве, можно догадаться о том, что каждому игроку соответствует своя ячейка массива. Т.к. каждый игрок имеет свой индекс от 1 до 32 (абсолютный максимум), чем не обделен и наш массив, проводим простую аналогию: игроку с определенным индексом соответствует тот же индекс массива, а следовательно и ячейка массива, она же "элемент". При этом нулевая ячейка массива остается неиспользуемой, поэтому наш массив и имеет размерность 33, а на не 32, как в случае с игроками.

Также в коде можно увидеть функции, например: MsgBarTime и fwMsgWeaponList. Первая из которых используется для отсылки клиенту сообщения (Msg -> message, сообщение), имеющего название "BarTime". Вторая - это forward (fw) функция, т.е. функция, вызывающаяся в момент, когда мод отсылает сообщение (Msg) с именем "WeaponList".

И так далее можно разбирать код по полочкам. Таким образом, чтобы эффективно читать код, необходимо в первую очередь разобраться в фундаментальных основах AMX Mod X скриптинга, в том числе в типах данных и прототипах функций. Также будет нисколько не лишним освоить венгерскую нотацию и общие принципы AMX Mod X и его скриптинга. Но и этого недостаточно для т.н. "полного понимания картины". Важным фактором здесь также будут знания внутренного устройства и функционирования: AMX Mod X, Metamod, а также самой системы сервер-клиент вцелом.

P.S.: Знаю, что тема раскрыта далеко не полностью, но все же лучше, чем ничего.