Извините, тема флуд, но душа кричит., Вот код есть мой: Код (Text): /** Никакой проверки на уникальность! Каждое подразделение само по себе уникально, если его org_id соответствует уникальному имени в division_name Несоответствующие поля - это принадлежность подразделения к иной организации Совпадающие поля division_name и org_id блокируются по DuplicateObjectException **/ public class DivisionRegistry { private Division div; /** NOT NULL CONSTRUCTOR! Будьте внимательны!. Нельзя создавать указатели в никуда: НЕ ПРАВИЛЬНО: Division div = null; ... new DivisionRegistry (div); -- Не верно, так как поля подразделения указывают в пустоту и их нечем заполнять. ПРАВИЛЬНО: Division div = new Division (0xЧисло); //По номеру, если извращение вытекает со всех дыр new DivisionRegistry (div); или new DivisionRegistry ( new Division ( "Бухгалтерия", // Наименование myCorp // Указатель на вашу Организацию ) ); // как следует. **/ Ну по чему в сапорт звонят челы, у которых вылетает NullPointerException всякий раз при попытке заполнить поля несуществующей структуры? Блин ну по таким мелочам (не только по этому ) я уже 14 входящих принял. Для кого коменты писал - не понятно Достали гады.
В данном конкретном случае надо писать не комментарии, а докумиентацию После чего со спокойной совестью посылать всех на ..., в ... и к ... .
CyberManiac +1. Хотя начальное нуление это нормально и такую ситуацию надо обрабатывать (в идеале невалидный пойнтер тоже). Ну и ехепшены тоже, если комковая либа конечно. Подробные комменты - это хорошо, а защита от дурака - лучше.
Есть документация в doxygen, подробная. Без толку! А руководство говорит что инцидентов (ну... когда юзер звонит с проблемой) чето много. Опять вызов - это ваще на баш надо. Проект - библиотека libcorporate.so, libcorporate.dll (для двух систем) На ее основе пишутся проги для кладовщиков, мастеров и прочей корпоративной толпы. Вопрос: Собрали проект. Не работает. Пишет что нужна библиотека libcorporate. что делать? Ответ: выполнить install, если копировать разучились. Капец просто!
Чем короче и понятней комментарий, тем он привлекательней.) Никто груды рукописного текста читать не будет - у всех мало времени, жизнь такая.
Тут - нет. Если тебе надо принять массив из символов, ты не знаешь скока их будет (например с терминала или сервака), то еще можно допустить конструкции типа char[] c = null; Но тут так задумано, что ты не можешь не знать, для чего создается объект. Как раз чтоб ошибок было меньше. А руководство не признает никогда что в других подчиненных предприятиях кодеры или укуренные или пьяные на работе.
Груды да, но неужеле трудно написать короткую и понятную доку. И доксигенов не надо, делайте нормальное описалово в pdf, html, chm. И чтобы там было всё по делу, без всяких пространных рассуждений. Сами-то небось любите нормальную доку.
Ursus В бухгалтерии? Да и трай много тактов не заберет. И не забывайте целевой аудитории. Бухпроггеры, обычно, не супер. А сверхбыстрые алгоритмы лучше организовывать внутренне с входным интерфейсом имеющим все проверки. Так будет спокойнее.
Да не трудно. Просто как-то стремно, боюсь обидеть читателя. Я всегда считал что если ты айтишник, то первое, что должно быть в твоей голове - здравый смысл. Представь, если тебя посылают за хлебом примерно так: Сходи за хлебом. В Хлебный магазин, понимаешь? В хлеб-ный. Если название магазина не "Хлебный", не ходи, иди в другой. Там есть хлеб. Это такой белый мягкий кирпич с знакомым тебе запахом. Это называется Хлеб. Его принеси. Домой. Не к соседу, а домой. Дом - это то место, откуда ты вышел. Не забудь запомнить дислокацию выхода.... Тебе приятно будет? Так и кодеру.
osrootd Причем тут приятность? Вы прогу не для человека пишете, а для компа. А комп - крайне исполнительный и крайне тупой. Те приведеное вами описание алгоритма похода за хлебом в магазин - абсолютно справедливо для компьютера. А если код закрыт, то для защиты от тупого кастинга и сигнатурки в интерфейсных классах не помешают. Или вы каждого юзверя уму научить собираетесь?
А javadoc разве не должен заканчиваться на "*/" вместо "**/" ? Мне кажется, что кодеры просто не используют IDE либо не знают как в ней читать javadoc. Я также не понял, а вас что все баги чужих кодеров заставляют исправлять? Раз они баг допустили, то пусть они и исправляют.
Я понял в чем проблема! Приводят следующий код ( со стула не падать, это - GCJ, там допустимо такое) Код (Text): extern "Java" { namespace blackoffice { namespace corporate { namespace subsystem { class OrganizationRegistry; } class Organization; } } } class blackoffice::corporate::subsystem::OrganizationRegistry : public ::java::lang::Object { public: OrganizationRegistry (::blackoffice::corporate::Organization *org); rebuild_Registry_Data (); // А вот сюда лезть не надо было Люди просто не знают, как работает gcc, как собираются приложения. Ситуация такая. Была толпа 1с-ников. Их сделали джавистами. Вот и глюки оттуда Ладно, переделали OrganizationRegistry.h, OrganizationRegistry.java соответственно как им надо, но rebuild_Registry_Data () - это нативная функция, и ее перестройка потребует изменения еще кучи сорцов. Просто Makefile надо было смотреть. Руководство от меня отстало после оценки кода другими спецами. Я оказывается написал нормальную работающую либу, а если кому не нравиццо, пусть идут учить язык, это бесплатно и быстро делается в конторе. Собственно, пока все путем.
Нечё на зеркало пенять, коль рожа крива - это правило должен принять каждый разработчик библиотечного кода, амбиции в топку. Если нет сил сказать себе - этот говонокод следует отрефакторить, запретить передачу в конструктор голого поинтера на приватный(!) класс, и комментарии не понядобятся, то остаётся делать вот такой профессиональный трюк - переложить проблемы на пользователей кода, у которых свои проблемы, бизнес-логика всякая.
