зачем ты вообще скидываешь два разных кода и зачем-то указываешь на их различие между 1.8.2 и 1.9? На деле второй сниппет кода будет выглядить практически идентичным даже если его написать на 1.8.2.
То есть что ты сделала:
смотрите какой лаконичный код на 1.8.2 скидывает код плагина 70 строк, который показывает ХП убийцы
зато ПОСМОТРИТЕ как "читабельнее" стало в 1.9 скидывает testsuite регулярок, который НЕ ЯВЛЯЕТСЯ ПОЛЬЗОВАТЕЛЬСКИМ ПЛАГИНОМ, а юнит-тестом
прелести серьезной разработки — явная передача параметров лучше, чем не явная. Представь функцию на 10 параметров. Расскажи мне как ты будешь передавать эти 10 параметров, не зная их порядок, но вспоминая их названия?
в него наоборот надо тащить все то, что только возможно на нем написать вместо того, чтобы делать это на c++, который трудно поддерживать и писать. Я надеюсь, что мне не придется объяснять назначение скриптовых языков и почему лучше больше кода на скриптовом языке, чем на каком-то вполне устаревшем и системном языке
karaulov, я не говорю про укорочение идентификаторов, я говорю об укорочении синтаксических конструкций, то есть public something -> @something. И я не претендовал и не говорил про то, что код так будет работать быстрее. Это проверенная практика: например, в питоне для protected модификатора доступа методов/свойств используется префикс _ к идентификатору, вместо ключевого слова protected перед идентификатором как в других языках.
Вчера в 15:14
сами имена переменных наоборот должны быть на столько длинные, на сколько необходимо чтобы передать достаточно смысла
karaulov, очевидно потому что это расширение макросом. Еще задай вопрос почему никто не пишет на этом
Дело не в том что это просто возможно, а дело в том как это легитимно определено разработчиками языка и как это принято среди разработчиков
Xelson, Что же вас так расстроило ? Вы противоречите своей аргументации про Pawn
в него наоборот надо тащить все то, что только возможно на нем написать вместо того, чтобы делать это на c++, который трудно поддерживать и писать. Я надеюсь, что мне не придется объяснять назначение скриптовых языков и почему лучше больше кода на скриптовом языке, чем на каком-то вполне устаревшем и системном языке
Так что должно быть короче а что длиннее ? Вот я тоже придерживаюсь мнения что имена переменных и функций должны доносить понимание об их предназначении чтобы н было вопросов и желания залезть в другие участки кода. Зачем появился amxmod ? для простоты скриптования локализованных задач, игровых и тд, где нет необходимости в полном доступе к памяти игр и проектов, а где есть ограниченная среда. Это делает создание модификаций более безопасным, для игр, и удобно для моддера. в Pawn нет строгой типизации, и много чего другого. Возможности языка позволяют сделать код удобночитабельным где просто продвинутый пользователь может что то перенастраивать изменять модифицировать для своего мода. Но тендеция показывает, что около движка собрались не моддеры в большей части а программисты, которым тесно в парадигме Pawn , и они хотят дотянуться дальше. Взять к примеру модуль Орфей. Мне не нравится что вы ломаете парадигму простоты в Pawn делая из него чудовище. что в конечном счёте приведёт к его вымиранию, ведь код ан нём станет не читабельным, а поддержка и отладка слишком трудозатратная, где проще будет написать под метамод или на чистом си (с++) с SDK , где всё дисциплинировано в одном стиле десятилетиями, по большей части. к Документации надо всегда прибегать чтобы проверять не только себя но и когда работаешь в чужом коде, Разница в функции где аргумент передается явно и неявно, с точкой и названием или только значением есть существенная, читаемость кода падает когда однострочная функция из 10 флот аргументов превращается в обзац из Евгения Онегина, а в документацию всё равно придётся смотреть чтобы понимать всю суть нэтива к примеру.
Кто то сказал: "всё гениальное просто". А гениальный скульптор берёт камень и отсекает всё лишнее. написать public мне проще чем плясать на шифте с @. А также читать, искать код удобнее. у модификатора public одно явное назначение, а @ может быть что угодно, например комментарии. Спасибо.
karaulov, очевидно потому что это расширение макросом. Еще задай вопрос почему никто не пишет на этом Посмотреть вложение 44080
Дело не в том что это просто возможно, а дело в том как это легитимно определено разработчиками языка и как это принято среди разработчиков
Так вот задумайтесь почему 15 лет почти никто не юзал @ , и придерживались одного тона, стиля написания ? почему плагины с alliedmodders так приятно и удобно читать ? Наверно это было негласным принятием правил хорошего тона. А потом кто то решил выпендриться аля "Ой да тут же можно так, вот я не буду как все буду так делать Ха." - Это моё личное мнение, и я на него имею право, Спасибо.
я не рассуждал в таких категориях. У меня нет инструкций к тому, что должно быть длинее или короче. Мы используем символы для того чтобы передавать семантику в тех местах, где это действительно критично, и сокращаем их где мы можем пожертвовать семантикой ради того, чтобы не писать лишние символы. Я не против использовать и public в плагинах, но при этом я не считаю нужным хейтить собаки. Самое ключевое здесь это однообразная конвенция кода
кто вы то? Мы ничего не ломаем. Этот рудимент был костылем для того чтобы дотягиваться до закрытых структур и процессов движка и геймлибы, сейчас он не нужен с появлением rehlds, regamedll и reapi. Факт существования этого фрик модуля не создает претендентов к вымиранию языка, между этими вещами, снова, просто нет никакой связи. Все нужные апишки сейчас предоставляет reapi, павн все еще остается прагматичным языком для моддинга
нет, читаймость кода не падает от этого а повышается. Неужели невозможность однозначно сказать что каждый из десяти флоут параметров означает, смотря на одну строчку кода, является высоким уровнем читаймости? Это скорее высокий уровень замешательства в те моменты, когда ты действительно хочешь разобрать эту строку и что-то там поменять
меня расстраивает уровень ведения дисскусии и серьезность поднимаемых "проблем". Вместо ответов на вопросы и вменяемой критики на мои тейки я выслушиваю поток сознания, который не имеет прямого отношения к заданным вопросам и к моим высказанным позициям. Уже не хочется продолжать
Ulianochka
Pawn, as a scripting language, is designed to let developers choose their own path. Whether you prefer "public", "@", verbose variable names, or concise ones. The compiled bytecode remains the same. The compiler is designed to handle all valid syntax uniformly.its all about what works for you. The beauty of Pawn is that it provides these options without forcing you into a single paradigm. I dont care is code readable, maintable sometimes you just dont care the main thing is how code is executing and running. And stop this stupid drama.
А также в changelog https://dev-cs.ru/resources/405/update/1012/ есть строка: (g/s)et_user_hitzones() functions weren't generating properly in the API due to a whitespace in front of the comment blocks. @return for give item() was missing Что означает @ перед retern ?
Ничего не означает. Это просто шаблон комментариев в инклудах.
Код:
/**
* Converts a flag string to a bitflag value.
*
* @note Example: The string "abcd" represents the sum of 1, 2, 4, and 8 - or
* (1<<0)|(1<<1)|(1<<2)|(1<<3). The function will return 15.
*
* @param flags Flag string to convert
*
* @return Bitflag value
*/
native read_flags(const flags[]);
пока не пришли Русские молодые мажоры, которые решили впихнуть туда всё для выпендрёжа. (но это ментальность у нас такая, любим вычурненность и вульгарность, ибо мало чем другим блеснуть можем.)
Код для AmxModX 1.9.0 может ничем не отличаться от кода для AmxModX 1.8.2. Зависит от человека, пишущего код, ибо кто как хочет, тот так и пишет. И обёртки далеко не каждый использует.
Отчасти согласен, но не всегда, иногда даже наоборот. Код, вынесенный в сток имеет название стока, чаще всего дающего понять, что именно он делает, и не приходится гадать, за что именно отвечает этот кусок кода, как если бы он был вне стока.
Так же, код выносится в стоки, если он дублируется несколько раз в одном и том же плагине, чтобы не раздувать общий код - тем самым способствуя улучшению читаемости, но никак не ухудшению, как у тебя написано.
Противно читать современный код плагинов на 1.9 потому что из за компактности, сложнее дебажить, ибо читаемость кода низкая. а уж про выпендрёж со стоками, дабы урезать пару строк кода в функции, создают проблемы читабельности кода. а это выливается в потери времени при отладке.
Ах да, и ещё кое-что. Плагины не делаются для того, чтобы в них копаться и их отлаживать. Они выкладываются в готовом виде, выполняя определённый функционал. Поэтому лезть туда без особых причин нет нужды. Ставишь на сервер и используешь.
Так, так, так. Погоди. Во-первых, откуда инфа что первый код для 1.8.2?) Он в таком же виде работает и на 1.9.0. Во-вторых, причём тут второй код, который выполняет служебную функцию? Функцию тестирования amxx-модуля. Он не обязан быть читабельным, держу в курсе.
Если хочется сравнить, найди корректный пример. Жду ответа.
Я что-то пропустил, и использование деф названия входящих аргументов с точкой перед их именем ускоряет выполнения кода? Где это написано?
Отвечая на твой вопрос, приведу пример, как делаю я, а применяю я это в двух случаях. Когда натив имеет много аргументов, и чтобы при дальнейшей разработке не приходилось каждый раз открывать этот натив, чтобы понять, за что именно отвечает каждый параметр, я "подписываю" их таким образом.
Код:
/**
* Creates a beam ring between two entities.
*
* @note A common sprite to use is "sprites/laserbeam.spr"
* @note Video preview of this and all other te_ stocks can be found here:
* https://youtu.be/szW-bSMPuyQ?t=5m10s
*
* @param startent Primary entity id
* @param endent Secondary entity id
* @param sprite The sprite index to use in the beam
* @param startframe The frame to start with in the sprite (0 - 255)
* @param framerate The frame rate to show the sprite at (0 - 255)
* @param life The length of time the beam shall remain (0 - 255)
* @param width The width of the beam (0 - 255)
* @param noise The noise amplitude of the beam, this controls
* the distorsion of the beam (0 - 255)
* @param r Red color amount (0 - 255)
* @param g Green color amount (0 - 255)
* @param b Blue color amount (0 - 255)
* @param a Beam brightness (alpha) (0 - 255)
* @param speed The scroll speed of the beam (0 - 255)
* @param receiver Client index that will be able to see the beam
* or 0 for all clients
* @param reliable If true, the message will be sent via the reliable
* channel, otherwise it will use the unreliable one
*
* @return 0 if "receiver" is non-zero and the client isn't connected,
* 1 otherwise
*/
stock te_create_beam_ring_between_ent(startent, endent, sprite, startframe = 0, framerate = 30, life = 10, width = 10, noise = 0, r = 0, g = 0, b = 255, a = 75, speed = 0, receiver = 0, bool:reliable = true)
{
if(receiver && !is_user_connected(receiver))
return 0;
message_begin(get_msg_destination(receiver, reliable), SVC_TEMPENTITY, .player = receiver);
write_byte(TE_BEAMRING);
write_short(startent);
write_short(endent);
write_short(sprite);
write_byte(startframe);
write_byte(framerate);
write_byte(life);
write_byte(width);
write_byte(noise);
write_byte(r);
write_byte(g);
write_byte(b);
write_byte(a);
write_byte(speed);
message_end();
return 1;
}
Второй случай - когда я могу ограничиться стандартными значениями аргументов в нативе, кроме какого-то одного. И чтобы не переписывать стандартные значения, я указываю просто только тот аргумент, значение которого отличается от стандартного.
Код:
/**
* Sets display parameters for hudmessages.
*
* @note As of AMXX 1.61, setting the channel to -1 will automatically choose
* the next available HUD channel for the client.
* @note There are four different HUD channels available on the client (1-4).
* Sending a hudmessage to a channel will overwrite any existing messages
* already displaying on that channel.
* @note If you plan to create a permanent message, don't forget to specify a
* specific channel to avoid possible flickering due to auto-channeling.
* @note For the hudmessage coordinates x and y, -1.0 will center the message
* on the respective axis.
* @note These parameters stay until the next call to set_hudmessage overwrites
* them. Multiple calls to show_hudmessage will therefore re-use the same
* parameters. The parameters are not stored per-plugin, so other plugins
* can overwrite them.
*
* @param red Red component of hudmessage color
* @param green Green component of hudmessage color
* @param blue Blue component of hudmessage color
* @param x Location of the message on the x axis in percent
* @param y Location of the message on the y axis in percent
* @param effects Display effect
* @param fxtime Duration of the effect
* @param holdtime Time the message stays on screen
* @param fadeintime Time it takes the message to fully appear (fade-in)
* @param fadeouttime Time it takes the message to fully disappear (fade-out)
* @param channel Channel to use on the client
*
* @noreturn
*/
native set_hudmessage(red = 200, green = 100, blue = 0, Float:x = -1.0, Float:y = 0.35, effects = 0, Float:fxtime = 6.0, Float:holdtime = 12.0, Float:fadeintime = 0.1, Float:fadeouttime = 0.2, channel = -1);
Меня устаивают стандартные параметры, кроме длительности показа сообщения. Делаю так:
Это вообще про что? Какой фпс? Серверный? Клиентский? Видео с замерами фпс с зелёным чатом и с стандартным стоит ждать? Или хотя бы ссылку на источник данной информации?
У меня вот лично есть информация от человека, разрабатывающего неофициальный кс клиент, что сообщения в игровом чате априори способствуют просадкам фпс, не важно какого цвета.
А про обёртки функций в 3 слоя, это я почитала что вы в стоках меряете линейкой у кого макрос круче и сделала вывод, что от таких обёрток часто только вред, ибо простая функция, занимает 3 сточки, а они делают с обёртками в 1 сточку, но читать не возможно код потом.
Наверное удивлю тебя, но в данном сообществе тоже есть не только негласные, но и даже очень гласные Требования к плагинам в ресурсах.
Итак, это всё, что я хотел сказал на текущий момент.
Заранее благодарю за ответы на мои вопросы, и за предоствление ссылок или иных доказательств по моим просьбам.
Буду с нетерпением ждать продолжения этого обсуждения!
karaulov, очевидно потому что это расширение макросом. Еще задай вопрос почему никто не пишет на этом Посмотреть вложение 44080
Дело не в том что это просто возможно, а дело в том как это легитимно определено разработчиками языка и как это принято среди разработчиков
На данном сайте используются файлы cookie, чтобы персонализировать контент и сохранить Ваш вход в систему, если Вы зарегистрируетесь.
Продолжая использовать этот сайт, Вы соглашаетесь на использование наших файлов cookie.