Сообщение от
DeimoS
Я понимаю о чём ты говоришь в целом, но как твои слова относятся конкретно к этому случаю? Когда все "минусы" распространяются лишь на администрацию, которая этой командой вдруг начнёт пользоваться, решит написать буквы вместо числа и её телепортирует по координатам, которые закреплены за нулевым ID.
Мои слова относятся к этому случаю в том плане, что в нём и оптимизировать-то особо нечего. То, что ты сделал, обычно называют "преждевременной оптимизацией". Ну откажешься ты от использования sscanf, в лучшем случае выиграешь пару-тройку микросекунд, общей картины это не изменит. Хотя можно было просто использовать sscanf2 и сэкономленное время потратить с куда большей пользой на оптимизацию того, что действительно нуждается в оптимизации.
Сообщение от
DeimoS
По-моему, ты слишком преувеличиваешь сейчас...
Ты не видишь меры в том, что стоит оптимизировать, а что нет, да ещё и меняешь логику работы кода, чтобы достичь ещё большей "оптимизации", я лишь констатирую этот (очевидный) факт. О каком преувеличении здесь может идти речь?
Сообщение от
DeimoS
Вариант "для паблика" и вариант "для себя" мало чем отличается. Это не как, например, написать программу с закрытым исходным кодом, но такими изощрёнными методами (дающими больший прирост к скорости), которые и поддерживать, и показывать кому-то страшно.
Нет. Просто когда я пишу "для себя", я использую "изощренные методы", которые хорошо известны мне и предназначение которых я прекрасно понимаю, которые я часто использую, и альтернативные ("правильные") варианты написания которых я так же прекрасно знаю. И мне не составит труда сделать то же самое, но "правильно", если это потребуется ситуацией.
Для паблика так тоже можно: если используешь что-то нестандартное, просто снабди комментарием, чтобы другим было понятно. Но, опять же, в меру.
В качестве примера приведу пару своих работ:
http://pro-pawn.ru/showthread.php?3243
Здесь в функции используется #emit для того, чтобы вместо двух операций деления с одинаковыми операндами оставить лишь одну и тем самым повысить производительность алгоритма.
В комментарии указан оригинальный код на Pawn и причина, по которой был использован тот трюк с #emit.
http://pro-pawn.ru/showthread.php?12837
Здесь тоже используется #emit, и не один раз. Это обусловлено тем, что куй объявил функцию SetPVarString без спецификатора const для параметра "varname", из-за чего просто невозможно перехватить BanEx без #emit, не нарушив совместимости.
Собственно, всё это так же можно найти в комментариях.
Сообщение от
DeimoS
Как по мне, именно такого, более гибкого, подхода должен придерживаться каждый. Именно тогда это можно назвать творчеством и именно тогда это можно назвать более профессиональным подходом (знание всех аспектов написания определённой системы).
Так я и не говорил, что следует абсолютно всегда придерживаться шаблонных методов.
Сообщение от
DeimoS
И тем меньше шансов придумать что-то поистине новое. Твой подход, как по мне, правилен для работы (для "серьёзного" программирования). Когда ты пишешь код для себя, что тебе мешает экспериментировать? Хуже, чем уже придумали, ты вряд ли сделаешь, если ты знаком с тем, что уже придумали и как к этому дошли. При этом, ты лучше поймёшь то, как до придуманного дошли и какие ещё есть варианты реализации того, над чем ты работаешь. В общем, по-моему, это и есть то самое творчество, о котором ты говоришь.
Для экспериментов можно делать отдельные небольшие работы, чтобы обкатывать новые техники программирования. В случае, если допустишь какую-то значительную ошибку или эта техника просто не оправдает себя, тебе не придётся тратить время на поиск и откат изменений в основном проекте.
Нужно уметь отличать какой-либо свой проект от "испытательного полигона". В крайнем случае, эксперименты можно проводить, реализуя с нуля отдельные модули проекта, но не в уже готовом и проверенном коде.