Здравствуйте, alzt, Вы писали:
AD>><offtopic> AD>>Не соглашусь! Совершенный код — это ненаписанный код. Но это уже совсем другая тема AD>></offtopic>
A>Пустое множество обладает любыми свойствами.
В том числе и совершенством А на другие свойства мы закроем глаза
Здравствуйте, wraithik, Вы писали:
W>Я помню свою первую VCL на ТурбоПаскале, когда я через полгода полез в нее, то долго думал что же такое TA,TB,TX,TY, а потом зачем я это все писал. После этого писать комментарии вошло в привычку. И если есть возможность, надо давать такие имена переменным, чтобы было сразу понятно, что это такое, но это уже больше из 1Ски. В плюсах вроде как не принято давать длинные имена переменным. W>Код должен быть читаемым. Чтобы найти Access Violation зачастую не надо знать алгоритм досконально.
Паскаль изначально разделяет переменные и код, т.е. затрудняет чтение и написание программы. Поэтому я на нем и не пишу. С++ (но не С) в этом отношении гибок, позволяя создавать переменные в месте использования, и тем самым не мешает писать длинные но легко читающиеся коды.
Access Violation вообще не считаю проблемой для отладки, хотя тут многие поминают именно ее. Отладчик вам уже показал место сбоя — чего же лучше? Гораздо интереснее ошибки, не дающие себя проявлять. Даже утечки тут не в счет.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Access Violation вообще не считаю проблемой для отладки, хотя тут многие поминают именно ее. Отладчик вам уже показал место сбоя — чего же лучше?
AV может случиться совсем не там, где происходит ошибка. Например при расстреле памяти.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, alzt, Вы писали:
A>Лучше такой код прогонять через что-нибудь. Хотя бы через препроцессор Си. A>В общем, ограничение хотя бы на размер переменных снять не сложно при желании.
Я, может, так бы и сделал. Только та софтина работала не на PC. Аппарат назывался "Искра-226", там вся ОС — интерпретатор Бейсика. Там не было даже речи о Си. Даже ассемблер вызывался каким-то хитрым образом из Бейсика.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>У тебя же код, который как ни форматируй, как на функции не разделяй — все равно понятным не сделаешь, так как в нем некая не слишком тривиальная математика, которую нужно просто знать, и не из программы.
Как я уже писал, в таких случаях принято в начале программы делать небольшой пояснительный текст. В нем указывается, какие алгоритмы используются, и какой первоисточник. Если сверяться с первоисточником, код становится вполне читаемым. И такие пояснения делались и в каменном веке эпоху перфокарт.
Здравствуйте, Privalov, Вы писали:
P>Как я уже писал, в таких случаях принято в начале программы делать небольшой пояснительный текст. В нем указывается, какие алгоритмы используются, и какой первоисточник. Если сверяться с первоисточником, код становится вполне читаемым. И такие пояснения делались и в каменном веке эпоху перфокарт.
Отчасти согласен, но только отчасти.
В программах с серьезными математическими алгоритмами это не совсем пройдет, ну хотя бы потому, что формулы в привычном виде туда не вставишь. Да и описать алгоритм в виде plain text не всегда возможно. Ссылки дать, конечно, можно. А вообще к такой программе надо делать специальный документ, там все и описывать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В программах с серьезными математическими алгоритмами это не совсем пройдет, ну хотя бы потому, что формулы в привычном виде туда не вставишь. Да и описать алгоритм в виде plain text не всегда возможно. Ссылки дать, конечно, можно. А вообще к такой программе надо делать специальный документ, там все и описывать.
Нормально все пройдет.
Во-первых, человек, который совсем не в теме, в такую программу не полезет.
Во-вторых, в журнальных статьях, монографиях, учебниках, даже диссертациях plain text не используется с незапамятных времен.
В-третьих, в программу вставляется не описание алгоритмов, а только ссылка на него.
В-четвертых, чтобы формулы были похожи на привычные, их стоит записывать так, как они выглядят в источнике. Т. е. не выдумывать имена типа SomeValue = MyCoolFunction(Argument), а писать просто: y = f(x). Желательно, на Фортране.
Разумеется, есть нюансы. Ну там вынос общих подвыражений, определенные преобразования формул для удобства кодирования. Но те, кто программирует серьезный матан, затруднений, натыкаясь на такое, не испытывают никаких сложностей.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>У тебя же код, который как ни форматируй, как на функции не разделяй — все равно понятным не сделаешь, так как в нем некая не слишком тривиальная математика, которую нужно просто знать, и не из программы.
P>Как я уже писал, в таких случаях принято в начале программы делать небольшой пояснительный текст. В нем указывается, какие алгоритмы используются, и какой первоисточник. Если сверяться с первоисточником, код становится вполне читаемым. И такие пояснения делались и в каменном веке эпоху перфокарт.
не надо ничего писать "в начале программы".
всё должно быть написано максимально близко к тому, к чему оно относится. иначе оно быстро устареет или потеряется
Здравствуйте, Privalov, Вы писали:
P>В-четвертых, чтобы формулы были похожи на привычные, их стоит записывать так, как они выглядят в источнике. Т. е. не выдумывать имена типа SomeValue = MyCoolFunction(Argument), а писать просто: y = f(x). Желательно, на Фортране.
источник это хорошо, но с понятными именами читать приятнее.
Здравствуйте, Privalov, Вы писали:
P>Для математиков такая нотация привычна, они читают ее совершенно свободно.
Они не только читают это свободно, они явно предпочитают именно такую нотацию,
а принятые в среде ылитных программистов наименования типа YetAnotherFunctionWithOneCoolAlgorithm,
вот это их удручает и рушит им все эстетические чувства.
Здравствуйте, niXman, Вы писали:
X>наверное потому, что способ получения размера стека для POSIX и вендуз — разные?
Да нет, всё что касается непосредственно работы со стеком и регистрами там вынесено в boost/libs,
и используется, в случае с компиляцией с GCC, не POSIX, а написано всё на ASM, и там почти то же самое,
что и в POSIX-вых setcontext. Но над этим функционалом, который в POSIX выведен в пару-тройку библиотечных
функций, в boost нагромождена матрёшка из объектов, наследующих друг друга и переплетающихся друг с другом,
и все они, в своём определении, раскиданы по папкам, хотя можно было сделать как в STL-все объекты в одном-двух
файлах.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>>Паскаль изначально разделяет переменные и код, т.е. затрудняет чтение и написание программы.
ARK>Если писать функции на 200 строк, то да.
ARK>А нормальный код переменные в начале метода не портят.
Ну что значит "нормальные", я вот показал алгоритм в 1000 строк, который совсем не просто сократить. Такой на Паскале бы читался очень тяжело, и отлаживался тоже. А скорее всего, вообще не был бы написан , разработка никогда бы не была выполнена.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Здравствуйте, wraithik, Вы писали:
W>>Я помню свою первую VCL на ТурбоПаскале, когда я через полгода полез в нее, то долго думал что же такое TA,TB,TX,TY, а потом зачем я это все писал. После этого писать комментарии вошло в привычку. И если есть возможность, надо давать такие имена переменным, чтобы было сразу понятно, что это такое, но это уже больше из 1Ски. В плюсах вроде как не принято давать длинные имена переменным. W>>Код должен быть читаемым. Чтобы найти Access Violation зачастую не надо знать алгоритм досконально.
ЮЛ>Паскаль изначально разделяет переменные и код, т.е. затрудняет чтение и написание программы. Поэтому я на нем и не пишу. С++ (но не С) в этом отношении гибок, позволяя создавать переменные в месте использования, и тем самым не мешает писать длинные но легко читающиеся коды.
Никогда не было проблемой прыгнуть к секции VAR и наплодить переменных. Но не стоит писать огромные процедуры. Как правило есть блоки идентичные кода в двух и более процедурах, эти блоки надо выносить в отдельные процедуры. И отлаживать проще маленькими порциями, а не огромным блоком кода.
ЮЛ>Access Violation вообще не считаю проблемой для отладки, хотя тут многие поминают именно ее. Отладчик вам уже показал место сбоя — чего же лучше? Гораздо интереснее ошибки, не дающие себя проявлять. Даже утечки тут не в счет.
Он то показал. Теперь осталось понять что к этому привело и что хотел автор кода. Для этого код должен быть читаемым.
Ты можешь конечно дальше упираться, это ничего не изменит.
И да, все маджик-нумберы надо прятать в константы. И желательно не const THREE = 3.
V>Пиписьками решили померяться? Извольте. V>Ничего, что я работаю удаленно на несколько иностранных компаний, занимаясь разработкой софта в 3D моделировании и алгоритмировании операций с твердотельными объектами? Пользуясь моими разработками в этой области людям делают протезы на зубы и размещают краны на строительных площадках и разрабатывают новые модели механических часов и ювелирных изделий? Причем я посылаю заказчикам именно исходники. И все довольны. Ну ка...
Это не профессионально. Профессионалы сразу называют длину в сантиметрах
Здравствуйте, Handie, Вы писали:
V>>Пиписьками решили померяться? Извольте. V>>Ничего, что я работаю удаленно на несколько иностранных компаний, занимаясь разработкой софта в 3D моделировании и алгоритмировании операций с твердотельными объектами? Пользуясь моими разработками в этой области людям делают протезы на зубы и размещают краны на строительных площадках и разрабатывают новые модели механических часов и ювелирных изделий? Причем я посылаю заказчикам именно исходники. И все довольны. Ну ка...
H>Это не профессионально. Профессионалы сразу называют длину в сантиметрах
Ну у нас же вроде форум программистов, а не психотерапевтов.
Комментировать код неинтересно, он реально плохой. переменные то через подчерки, то в кемел стайле, то с префиксом m_.
Во первых написание крутого и сложного кода является признаком джуниора, для меня признаком синьора является написание простого и понятного кода. Синьор не пишет божественные классы и не смешивает алгоритмы с системными API.
Во вторых, какой-бы ни был шеф, его надо уважать. Если уважения к руководителю нет, то с очень высокой вероятностью придется покинуть компанию.
В третих, я считаю крайне вредным выносить мусор из избы и начинать разбор полетов на публичном ресурсе. Очень много лет назад я сделал эту ошибку и меня хорошо так полили разными отходами жизнедеятельности. Если Юрий Лазарев — это реальное имя, то в ближайшие годы найм будет крайне затруднен, гуглом умеют пользоваться почти все.
V>Еще ты, похоже, из тех "мастодонтов", которые еще на фортране и с перфокартами бегали. Так вот, такие обычно глухи к любым замечаниям "этих сосунков, которые еще под стол ходили, когда я уже дифуры программировал".
Пожалуйста, не надо всех по формальному признаку под одну гребёнку....
