Форум Программирование В помощь новичкам и любителям. |
|
пруф на самом деле простой - "проблема 2000 года". Программист не всегда может придумать возможные testcase. Или пример с кода, который видел на предыдущей роботе. Для записи в лог событий использовался номерок в виде int. Он обнулялся в полночь. B все было прекрасно долго, пока на одном с объектов не начились проблемы. Причем они возникали в произвольные моменты времени, а перезапуск не давал никакого позитивного результата... а все дело в том, что на объекте немного обновили конфигурацию сети и в лог писались в цикле ошибки с большой скоростью и кол-во событий стало больше 231. В сопроводительной документации программисты писали о том, что 231 достаточно большое число и его должно с лихвой хватить. Галочка "подтверждения прочтения" - вселенское зло. | ||||||
|
Цитата (Вадим К): В тридевятом управлении, на тридесятом объекте... Это всё конечно здорово, но я спрашивал: каким образом целочисленное переполнение может просочиться мимо специально сгенерированного кода для проверки целочисленного переполнения. PS: в той байке взыскание заслужили не разработчики, а эксплуатационники, которые, не читая документацию, добились того, что журналирование велось со виконання програми розпочинається з того самого мiсця, де призупинилося. | ||||||
|
как может просочится? Если это код, который поставил разработчик - он может просчитаться (никто не идеальный). Если это код, который сгенерирован компилятором, то при возникновении исключение, будет раскрутка стека. А многие разработчики любят клепать try - except, который глушит все. Особенно это актуально в тредах. (там необработанное исключение завалит приложение), поэтому добавляют, потому что приложение валилось, а нужно сдавать). Конечно, в небольших приложениях можно обложится параноидальными проверками, но в продакшине за всем не уследишь. А правильное приложение, в котором код вычислил любое исключение (не только переполнение) должен либо упасть в дамп, либо попытаться корректно восстановиться. И для продакшина первое часто неприемлемо, нужна работа 24/7/365. И вот тут переполнение может и просочится - ведь компилятор не подскажет, как правильно откатиться после исключения, какие выставить значения переменных и так далее. Получается, все проверки есть, все отловили, а "фантомное" значение переменной - просочилось. "фантомное" - потому что я не могу гарантировать, что компилятор не добавит какого то оптимизационного кода и не накрутит там. Но если видеть ассемблерный код, то можно предугадать значение. Но есть ещё один вид целочисленного переполнения, против которого не поможет компилятор. Это логическое целочисленное переполнение. Это я и привел с примером 2000 года. Галочка "подтверждения прочтения" - вселенское зло. | ||||||
|
Недавно писал СУБД и нафигачил одну из самых грубейших ошибок написания кода. SG_Fix.Cell[i,0]:=MyResult('Id'); ... SG_Fix.Cell[i,13]:=MyResult('Comment'); Такой код был во многих местах одного модуля. Использовался для заполнения таблицы результатами запроса по различным фильтрам (14 фильтров). При оптимизации кода данный текст я вывел в процедуру TForm1 = class(TForm) public procedure FillTable(); end; И просто в необходимых местах да и из других модулей мог заполнить таблицу как мне надо. Подобный пример привожу ибо у многих новичков наблюдал нечто подобное. Кодер второго поколения. | ||||||
|
Да кстати, про правила вывода процедур и функций. Т.е. разделения на методы напишет кто-нибудь? Чисти код! Чисти код! Чисти код! | ||||||
|
Цитата (Gooddy): Да кстати, про правила вывода процедур и функций. Т.е. разделения на методы напишет кто-нибудь? А теперь поясни, плиз, что ты под этим подразумеваешь. Я не понял. Делаю лабы и курсачи по Delphi и Turbo Pascal. За ПИВО! Пишите в личку, а лучше в аську. А ещё лучше - звоните в скайп! | ||||||
|
Цитата (min@y™): Да кстати, про правила вывода процедур и функций. Т.е. разделения на методы напишет кто-нибудь? А теперь поясни, плиз, что ты под этим подразумеваешь. Я не понял. Нужен пример И кстати, ещё нужно объяснить как (и главное почему) нужно переименовывать модули, объекты и классы (TForm1, Button100500, Unit5000 и т.д.). Чисти код! Чисти код! Чисти код! | ||||||
|
Цитата (Gooddy): и то как всё это разбивается на 5-10 раздельных методов. Ну, это уже личное дело каждого. Цитата (Gooddy): И кстати, ещё нужно объяснить как (и главное почему) нужно переименовывать модули, объекты и классы (TForm1, Button100500, Unit5000 и т.д.). А про это я уже писал. Имена идентификаторов должны быть информативными. Делаю лабы и курсачи по Delphi и Turbo Pascal. За ПИВО! Пишите в личку, а лучше в аську. А ещё лучше - звоните в скайп! | ||||||
|
Цитата (min@y™): Ну, это уже личное дело каждого. Я имею ввиду объяснить общие принципы, когда не следует выделять ни в коем случае, как следует выделять, где нужно обязательно выделять методы и т.д. Цитата (min@y™): А про это я уже писал. Имена идентификаторов должны быть информативными. Я про это тоже писал, нужно банально упомянуть то, что объекты и модули после создания нужно переименовывать. Чисти код! Чисти код! Чисти код! | ||||||
|
Цитата (Gooddy): Я имею ввиду объяснить общие принципы, когда не следует выделять ни в коем случае, как следует выделять, где нужно обязательно выделять методы и т.д. Общие? А они, вообще, существуют? Цитата (Gooddy): нужно банально упомянуть то, что объекты и модули после создания нужно переименовывать. Ну так упомяни. Стесняешься, что ли? Делаю лабы и курсачи по Delphi и Turbo Pascal. За ПИВО! Пишите в личку, а лучше в аську. А ещё лучше - звоните в скайп! | ||||||
Перейти в раздел:
© 2004 - 2024, Delphi.int.ru |
Версия форума: 1.10 (19.01.2010) |
Выполнено за 0.02 сек. |