Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
Форум программистов > Java: Общие вопросы > Советы по хорошему стилю |
Автор: nornad 14.6.2007, 03:01 | ||||
Не нашёл здесь такой темы, но считаю, что она будет полезна многим. Возможно, даже многим из тех, кто уже давно считает себя не новичком в Java. В общем, идея проста - все, кому есть, что сказать, предлагают свои советы по тому, как писать код в хорошем стиле. Чтобы было понятно, приведу пару советов из тех, что в последние дни вычитал на форуме: 1. Если в метод были переданы некорректные данные, выкидываем исключение вместо тихого-мирного притягивания данных за уши к корректному виду. Пример. плохо:
лучше:
2. При переопределении метода equals() надо переопределять ещё и hashCode(). Причём хэшкод должен быть равен для объектов, если они эквивалентны (equals() == true). P.S. Понятно, что многим подобные вещи известны и они пользуются ими не задумываясь. С другой стороны, всё знать нельзя и скорее всего каждый найдёт для себя что-то интересное в этой теме. Ну, или вспомнит хорошо забытое старое. ![]() |
Автор: RebornCrusader 14.6.2007, 08:19 |
Сюда же: имя параметра в setter-методе желательно иметь соответствующим имени метода, также как имя поля. И пара придирок к вашему коду: на мой взгляд, охватывающие скобки "{}" в if следует ставить всегда, когда условие тривиально и не входит в единственную строчку. При глубине вложенности больше 2-х это сильно упрощает чтение. Также я бы печатал значение параметра weight, чтобы сразу было понятно что с ним не так. Программу это не усложнит, а при отсутствиии доступа к исходников упростит локализацию ошибки (в том числе в этой проверке). И кстати: такое "исправление внутри" может быть удобным и вполне имеет право быть применимым если : 1) Это private метод (наши грабли) 2) Факт описан в javadoc (документированные грабли) Иначе придётся писать как "культурный" метод, так и враппер к нему. Я не сильно разделяю такую точку зрения, просто привожу её как контрпример. Прошу не принимать близко к сердцу ;) Второй пунк описан в каждом учебнике по Java. А IDEA так парой и предлагает их генерить... P.S. Хорошая тема, надо развивать. Только нужно структурирование. Люди пишут программу, отмечают "тру-решение" или наоборот , постят сюда - только кто возьмётся за сортировку? |
Автор: val 14.6.2007, 09:47 | ||
Не думаю, что это всегда так... Такой подход, конечно, весьма практичен, но засоряет код лишними try/catch блоками... Кроме того, exception зачастую подразумевает исключительную ситуацию, которая связана с принципиально непреодалимой ошибкой, ну а в примере ошибка более чем преодолима и может встречаться довольно-таки часто. |
Автор: w1nd 14.6.2007, 13:01 | ||
Дополню. Если создаётся наследник класса, в котором переопределёны equals() и hashCode(), в классе наследнике их следует переопределить обязательно. |
Автор: nornad 14.6.2007, 19:24 | ||||||||||||
На всякий случай поясню: я согласен с приведённым мною примером, но авторство не моё - в одной из тем именно этот пример дал LSD. Мне, конечно, приятно собирать лавры, но в данном случае они не мои. Первый пример тоже не мой, но автора я уже не помню (пример взят из темы "Маленький тест"). По поводу засорения кода блоками try-catch. Имхо, лучше засорить код такими блоками и получить взамен более простой и удобный способ обнаружения и устранения ошибок. К своему стыду должен признать, что не читал таких учебников. Даже TIJ до сих пор только издалека видел.
Если я правильно понял, то это звучит так: Если мы в классе А переопределили equals+hashCode, то и в классе Б (наследнике от А) их тоже надо переопределить. Думмаю, так чуток яснее.
Предпочитаю не захламлять код лишними блоками и пользуюсь следующим правилом: 1. если условие динное (из нескольких частей, либо просто больше 20-30 символов), переносим оператор (то, что надо выполнить) на следующую строку. Замечу, что это верно только для if с одним оператором - блоки всегда структурирую в отдельных строках, не считая самих скобок. 2. если в коде идёт сложная структура из операторов if, то в каждом обязательно обрамляем оператор скобками блока (даже если оператор один). Это позволяет избежать неверной работы, когда мы используем if-else. Пример:
Это плохо, т.к. выглядит и работает по-разному. Чтобы работа соответствовала виду, надо сделать хотя бы так:
Но я в таких случаях предпочитаю везде поставить блоки (иногда через пару дней лезешь в код и видишь, что надо добавить ещё один if - тогда-то блоки и спасают от вероятности приделать новый if не к месту).
Если честно, не понял. Опиши шире, что ты имеешь в виду. |
Автор: powerOn 14.6.2007, 20:49 | ||||
Если у вас в коде есть константа и переменная типа String, которые нужно сравнить, то всегда вызывайте метод equails на константе: плохо:
хорошо:
|
Автор: nornad 14.6.2007, 20:58 | ||||
Небольшое дополнение. Иногда нет необходимости выделять константу в собственное поле (по-хорошему, всё же лучше выделить), но совет всё равно стоит использовать:
Добавлено через 4 минуты и 35 секунд Кстати, а вот и ещё один совет. Просто, обозначу его явно: Все строковые константы желательно выделять в поля. Это относится к дефолтовым значениям строковых полей, названиям кнопок, страниц и панелей. Единственное исключение - пустая строка. И немного расширим: Все константы (любого типа) желательно выделять в поля. Исключения - пустая строка, 0 и т.п. |
Автор: y3u 14.6.2007, 21:47 | ||||
missorted modifiers, private string constant... я бы сделал так
|
Автор: powerOn 14.6.2007, 22:02 | ||||
Я думаю что подобные константы всегда нужно выносить в поля, хотя с по поводу пустой строки согласен. Это так называемые "magic numbers" (это обычно к числам относится, поэтому и "numbers"). Их тяжело искать в коде, да и если константа используется в нескольких местах, что чаще всего и бывает, то корректировать их во всех участках кода не есть благородное занятие.
А еще лучше учитывать интернационализацию и все названия GUI контролов читать из bundle-файла, тогда вопрос выделения их в поля просто не будет иметь место. Добавлено через 41 секунду очень может быть ![]() |
Автор: Maksym 14.6.2007, 22:05 | ||||
nornad
А чем 0 лучше других чисел?
Думаю, эти вещи нужно не выделять в поля, а хранить в properties файле и доставать через ResourceBundle. |
Автор: nornad 14.6.2007, 22:25 |
Тем же, чем и пустая строка "лучше" остальных строк. Кстати, к "исключительным" магическим числам, имхо, стоит отнести и -1 - очень часто это означает "неверный индекс/вариант". То есть, если 0 используется для проверки на пустоту списка (по количеству элементов), то не стоит его выносить в отдельное поле. Также и -1, если она используется, скажем, для определения, есть ли выделение в таблице (JTable.getSelectedRow(), например). |
Автор: Maksym 14.6.2007, 22:37 | ||
Пустую строку не использую как константу, просто потому что это не читабельно (непонятно, что она должна означать), а строковая константа своим значением как правило несет какой-то смысл тому, кто читает код.
Это я и имел в виду. Ноль в группе других числовых констант ничем не выделяется. В то же время, он как количество элементов списка -- очевиден. А как результат выполнения операции -- почти очевиден.. |
Автор: RebornCrusader 15.6.2007, 07:44 | ||||||
Создать что-то типа справочника "как надо" и "как не надо" - набор практических советов. Люди постят идеи в форуме, определённый человек их отфильтровывает и подкладывает в какой-нибудь FAQ. Строго по пунктам, со всеми "за" и "против", но лаконично. Для начала можно просто в начале темы. Можно выделить такие тематики как "косметическое оформление", "часто используемые конструкции" и т. д. в ширь и вглубь - по мере накопления материала. И вообще я согласен с тезисом, что даже на глубоко тривиальные иногда нужно указать - не всегда они приходят легко и сразу.
Я как-то для себя решил не усложнять такие вещи. Либо if в одну строчку (обычно с break, return или throw), либо if полноценный - потенциально многострочный. Вколотить туда отладку какую-нибудь или логи опять же удобней...
Не совсем согласен. Если данная строка текста используется в нескольких местах (в классе), в поле её загнать прямой резон. Но и из бандла читать:
На первый взгляд громоздко, зато ошибиться потом просто невозможно. Строки, используемые в GUI однократно, имеет смысл загружать на ходу (всё равно они там где-то кэшируются). Незачем засорять класс лишними константами, если они нужны только в одном методе и один раз. Только если уверен, что завтра они не понадобятся ;) И на счёт ResourceBundle. Даже если не думать об интернализации, редактировать строки в ресурсном файле всё равно в разы удобнее, чем в исходнике, где они раскиданы по всем тексту. К слову о константах. Читая книжки, натыкаешься чуть ли не на холивары на тему - должны быть они public или private. Хотя на самом деле всё просто - как и остальные члены класса, они должны иметь тот модификатор, который соответствует их необходимости для наследников или внешних классов. |
Автор: nornad 15.6.2007, 20:16 | ||||
Это только совсем "для начала" - после пяти-шести советов начало темы так разбухнет, то тема будет грузиться слишком долго.
Согласен. Я понимаю, что equals+hashCode - тривиально, но лично я этого не читал раньше (ну, не люблю ходить к сану на сайт, а в книжках нормального описания не было). Даже при такой уверенности они могут понядобиться завтра или послезавтра. Но тут уже можно либо сразу всё подозрительное выделять в поля, либо выделять в поле как только потребуется во втором месте.
Предпочитаю делать либо public (если может пригодиться снаружи), либо protected (уже пару раз столкнулся с тем, что бывает необходимость в потомке изменить константу, а если она приватная, то приходится либо менять доступ, либо привешивать сеттер - в любом случае маразм). |
Автор: JUncle 15.6.2007, 20:30 | ||||
Нет. Охватывающие скобки нужно ставить всегда! Объяснение простое - тому, кто поддерживает код - будет гораздо легче вставить в блок какие-то операторы, чем сначала обрамлять в скобки, а потом... Да и от многих непоняток уберегает.
1 тоже можно отнести. |
Автор: nornad 16.6.2007, 00:48 |
Можно тогда пример, в каких случаях 1 говорит сама за себя? |
Автор: w1nd 16.6.2007, 02:28 | ||||||
или
или
И вообще, если о числах, то есть -N, -1, 0, 1, N. Всё, что N - выносится в константы, остальное - необязательно. |
Автор: RebornCrusader 16.6.2007, 11:22 | ||||
Не согласен. Пожертвовав не значащими здесь деталями, приведу пример:
ИЛИ
Какой код, по-вашему читается легче? А если ещё подобных методов-сеттеров много? И всегда ли могут быть другие операторы внутри if-а? Здесь вероятность крайне мала, да и исправить быстро, т. к. строчка короткая и простая. И вообще, никакой код не должен и не может учитывать всех возможных направлений расширения. Важно, чтобы наиболее вероятные и важные из них давались относительно легко. Всего нужно в меру и к месту. |
Автор: JUncle 16.6.2007, 16:58 | ||
А вот таких допущений приводить не нужно. Нельзя с определенность сказать, как будут изменять код. И сопротивляться изменению он не должен. Встречный укол - вот именно, а если их много, ох икать же будет программист, если сопровождающему придется везде что нибудь добавить... Второй вариант прекрасно читается, проблем не вижу. О первый сразу спотыкаешься. А вообще - спорить мне не хочется. Эти вопросы регламентирует документ компании об оформлении искходного кода. |
Автор: w1nd 16.6.2007, 19:16 |
Разумеется тот, который со скобками ;) |
Автор: Samotnik 16.6.2007, 21:28 |
К примеру я придерживаюсь (стараюсь) "Хорошего стиля программирования" , а он гласит , что после оператора if должны быть скобки {...}. ИМХО и читать понятно, и глазу привычней Вод! |
Автор: Stampede 16.6.2007, 22:42 | ||||||
Полностью согласен с JUncle. Но рационализация (не знаю, блин, как это по-русски - rationalisation... обоснование, что ли) этой привычки у меня другая. Тут дело не в том, что кому-то когда-то может быть придется добавить операторов, и мы мол хотим облегчить им труд, с каковой целью заранее заключаем все в блок. Если бы дело было только в этом, то это как раз не было бы хорошей практикой, ибо относилось бы к категории "ранней (преждевременной) оптимизации", что не есть гуд. Основная причина, по которой я тоже всегда заключаю условную часть в блок - это стремление к минимизации граблей. Дело в том, что не практике, и особенно в стиле "шустрого программирования" (agile programing), достаточно часто приходится заниматься рефакторингом, перекидывая и перекраивая куски кода. При этом нередко одиночный стейтмент превращается во множественный и наоброт, и если полагаться на безблочную запись, то можно по невнимательности запросто сломать логику работы условия. Особенно этому способствуют закомментирывания/раскомментирывания строк. Вот смотрите:
Но тут мы в какой-то момент решаем, что может быть ширину лучше оставить без изменений, и закомментирываем соответствующую строку:
Хопа! Вот мы и наступили на грабли. Кто хочет сказать, что уж он-то точно никогда так не лажанется, пусть первый бросит в себя камень ![]() Короче, подводя черту. При виде безблочного стейтмента в условии у меня сразу возникает чувство, что где-то в тылу заложена мина замедленного действия. И пока я его не исправлю, у меня так и будет "сосать под ложечкой" ![]() А про читабельность я уж и не говорю ![]() |
Автор: v2v 16.6.2007, 22:56 | ||||||
Stampede, привёл очень хороший пример. Я и сам
Что и другим рекомендую. ... Но я начинаю изучать Java переходя с С++(#) и мне не понятна следующее размещение этих самых скобок:
Помоему вот так удобней:
Почему в ява первая скобка не пишется с новой строки? И при просмотре кода проще контролировать где "потерялася" какая то скобка. |
Автор: nornad 16.6.2007, 23:41 |
а) Java - язык этих самых скобок. ![]() б) привычка. Я поначалу тоже не мог привыкнуть к такому виду, а сейчас привык. Чаще пишу в "жабовском" стиле, но если условие многострочное - открывающая скобка у меня обязательно есть и стоит на новой строке. |
Автор: Samotnik 17.6.2007, 01:59 |
Ну почему же, я всегда пишу с новой строки(скорее всего тоже с С/С++ осталось) ! |
Автор: RebornCrusader 17.6.2007, 02:26 | ||||||
Именно эту мысль я никак не мог выразить! Когда условие и выполняющийся оператор стоят в одной строке, я считаю превращение оператора в блок из одного излишним - комментировать также просто и надёжно. Но, согласен, это дело вкуса и политики организации. Однако если код организован так, что внутренний оператор не входит в одну строчку с самим условием, скобки обязательны - легко видеть границу вложенного кода. И это касается и других конструкций. Одну строчку отследить легко, перенос - уже труднее, поэтому и требуется соответствующее оформление. Имено поэтому я не могу полюбить Питон, из-за его "бесскобочной " вложенности. Главное в программе - читаемость кода. А уж скобочки добавить всегда просто. Может я зажрался, но IDEA делает это почти сама ;) На счёт скобки в отдельной строки - вредная привычка C, с которой переучиваешься за месяц, тем паче при наличии автостилизации в IDE. Корни привычки, на мой взгляд, лежат ещё в Pascal - уж там эти страшные beginы в переносить на нову строчку куда приятнее. И наконец, скобка на новой строке использовалась для комментария к функции:
В Java нужда в этом отпадает, так как есть javadoc Добавлено @ 02:29 Вот и причина разногласий ;) У каждого в глубине души свои представления о прекрасном ;) Добавлено через 10 минут и 25 секунд
(Я тоже сталкивался с таким мнением.) Потому что при правильной стилизации на этом уровне вложенности стоит заголовок соответствующего метода. Находится быстро, дело привычки. |
Автор: FcUK 18.6.2007, 18:07 |
чесно говоря..все это хорошо....но есть http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html написан в далеком 1999 году + есть Maintainability Index програмы...если он больше 100 - значит код хорошый..если менше - увы... |
Автор: niasilil 18.6.2007, 19:40 | ||
гы, "Сказано пацакам в клетке выступать, значит надо в клетке. Чё выпендриваетесь? " Добавлю. Для eclipse есть очень Checkstyle плагин, который подсказывает что не так. Рекомендую. |
Автор: nornad 18.6.2007, 20:18 |
Документ неплохой, но там тоже далеко не все моменты проясняются. А посему, в этой теме давайте не будем спорить по поводу того, как кому удобнее и красивше код писать (это я про те же скобочки), а либо давать рекомендации по объективно хорошему стилю, либо снабжать различные "имхо" соответствующими пометками (дабы меньше запутывать начинающих). |
Автор: val_vp 20.6.2007, 11:12 | ||
Прочитал и офигел как много копий ломается о скобки ![]() а рекомендации по хорошему стилю уже давно выработаны как общие:
и Дж.Блох Effective Java так и корпоративные в виде разных Code convension (кстати построенные на sun Code Conventions) и полиси но и те и другие сходятся в том, что стиль должен обеспечивать код сопровождаемый и читаемый (indents, {}, tabs vs. spaces), и сам стиль предотвращает различные ошибки и неудачности типа: для блока try {…} catch (…) ставь finally; не throws Exception, а кидай че-нибудь вразумительное (Illegalstatement...) и то только когда это ОЧЕНЬ НУЖНО (пример из жизни слышал на програмерской фирме фразу, а мы return-ами уже не пользуемся ма кидаем эксепшны) Поэтому, ИМХО, советы лучше давать в виде ссылок на эти источники. можно еще добааить в свете Java5 не злоупотреблять boxing/unboxing и использовать generics |
Автор: batigoal 20.6.2007, 11:30 | ||
Эти стандарты очень часто переопределяются на уровне организации. И, в частности, пункт о скобках у нас тоже оговорен вразрез с Java Conventions. |
Автор: val_vp 20.6.2007, 11:58 |
batigoal, дык проблема хорошего стиля это не столько indents и скобки (это просто плагином устанавливается раз написанным -- я тоже "дома" всю интенданцию табуляцией делаю на фирме 4 пробела) сколько делать его читаемым, сопровождаемым и "с защитой от глупых ошибок". Да вот пример прям рядом как сделать код несопровождаемым: http://forum.vingrad.ru/forum/topic-159672.html dB = (float) (Math.log(value==0.0?0.0001:value)/Math.log(10.0)*20.0); |
Автор: _Y_ 20.6.2007, 11:59 | ||
Не могли бы Вы чуть больше о нем рассказать? И еще. Здесь много говорится о скобках и числе строчек кода в них. Гуру, выскажите свое мнение об операторах, занимающих несколько строчек. |
Автор: batigoal 20.6.2007, 12:31 |
Есть еще, кстати, http://jalopy.sourceforge.net/, тоже неплохая вещь. |
Автор: nornad 20.6.2007, 14:26 | ||
Ну, не знаю, насколько это актуально. В 5-ой и 6-ой жабе автобоксинг - вполне нормальная штука и делать явное приведение, имхо, глупо. Посему хотелось бы узнать - зачем? |
Автор: LSD 20.6.2007, 14:30 |
Всем любителям выносить все в константы рекомендую почитать http://worsethanfailure.com/Articles/Enterprise_SQL.aspx статейку ![]() |
Автор: fixxer 20.6.2007, 14:31 | ||||||
Вы можете на вскидку сказать, что удалиться из списка, второй элемент или Integer со значанием 1? |
Автор: LSD 20.6.2007, 14:34 | ||||
Вопрос не в явном приведении, а в том что вообще boxing/unboxing снижает производительность. А автобоксинг к тому же, еще маскирует от программиста опастность возникновения NullPointerException. Добавлено через 2 минуты и 18 секунд
Я смог ![]() |
Автор: nornad 20.6.2007, 15:23 | ||
Насколько я понимаю, тут удаление должно идти по индексу. ![]() |
Автор: niasilil 22.6.2007, 02:41 | ||||
Много не расскажешь. Он предлагает вставлять комментарии где надо, подмечает где скобка не на том месте, предлагает переделать входные параметры в final. Достаточно много настроек, можно под себя построить то что не надо высвечивать. Вобщем, после него код очень красиво смотрится. Вот скачай и попробуй. Ах да, бесплатный. http://eclipse-cs.sourceforge.net/ |
Автор: Entry_N3 22.6.2007, 22:21 |
Предлагаю идти от противного: "http://www.nestor.minsk.by/sr/2006/02/sr60201.html" ![]() P.S. Только не надо писать что-то вроде "Из того, что на улице нет дождя, вовсе не следует, что на улице светит солнце". Это и так ясно. ![]() |
Автор: Samotnik 22.6.2007, 23:33 |
2 LSD Извиняюсь за offtop, просто новую тему глупо создавать!! Хотел узнать, а что означает эксепшн NullPointerException ? У меня он выскакивает, но все работает!! |
Автор: Entry_N3 23.6.2007, 00:17 |
Samotnik, Thrown when an application attempts to use null in a case where an object is required. These include: *Calling the instance method of a null object. *Accessing or modifying the field of a null object. *Taking the length of null as if it were an array. *Accessing or modifying the slots of null as if it were an array. *Throwing null as if it were a Throwable value. Applications should throw instances of this class to indicate other illegal uses of the null object. ![]() Шучу, по себе знаю, что иногда лучше спросить, чем самому искать ответ ![]() |
Автор: Samotnik 23.6.2007, 00:42 |
Entry_N3 ![]() |
Автор: niasilil 3.7.2007, 01:34 | ||
ой, какая прелесть. Смеялсо. |
Автор: Entry_N3 3.7.2007, 22:14 |
niasilil, ![]() |
Автор: nornad 13.7.2007, 22:20 |
Нашёл тут у Джоэла довольно интересную статью (раньше почему-то её не видел, хотя написана была в мае 2005-го) - http://local.joelonsoftware.com/mediawiki/index.php/%D0%9A%D0%B0%D0%BA_%D0%B7%D0%B0%D1%81%D1%82%D0%B0%D0%B2%D0%B8%D1%82%D1%8C_%D0%BD%D0%B5%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D0%BA%D0%BE%D0%B4_%D0%B2%D1%8B%D0%B3%D0%BB%D1%8F%D0%B4%D0%B5%D1%82%D1%8C_%D0%BD%D0%B5%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D1%8C%D0%BD%D0%BE, в которой автор последовательно описывает идею применения Венгерской Нотации (всем, кто как я не любит Венгерскую Нотацию, читать в обязательном порядке - есть дельные мысли, "реабилитирующие" её; жалею, что не потрудился найти и прочитать оригинальную статью Симони), а также о вреде исключений. Не скажу, что на все 100% поддерживаю Джоэла, но разумные мысли явно имеют место быть. |
Автор: y3u 14.7.2007, 12:25 | ||
да, почему-то я тоже на на 100% поддерживаю автора статьи... В частности, я думаю, что есть небольшое противоречие, между несоздаванием собстенного языка программирования и использованием венгерской нотации, т.к. некоторые могут фанатично подойти к этой концепции и превратить ее в жесткий стандарт, что и случилось с MS с системной венгерской... Но, такое соглашение должно быть в команде разработчиков, т.к., ИМХО, если делать всякие суффиксы понятные только кому-то одному из группы, то толку от этого ноль, т.к. делает код менее читабельным и понятным, придется тратить время на разборки что эти суффиксы означают, адаптироваться к стилю конкретного программиста, а это лишнее время и деньги... я думаю, что самое простое, что, кстати, в JAVA всячески пропогандируется, это по-человечески называть переменные и константы, не нужно писать sVar или usVar, почему бы не написать просто safeVariable и unsafeVariable... Можно, конечно, такие вещи еще и строго типизировать, чтобы просто было нелья использовать код неправильно, но, я считаю, что в примере, о котором идет речь в статье, оборачивать строки свомими врапперами - совсем уж лишнее... |
Автор: w1nd 14.7.2007, 12:58 | ||||
... и даже не хочу слышать любых других мнений, потому как венгерская нотация - действительно плохая штука, а исключения следует использовать при любом удобном случае. Особо про венгерскую нотацию: никогда не понимал, зачем делать свой код понятным для тех, кто не знает языка.
И ещё, похоже, человек не знает о существовании checked exceptions ![]() Любым инструментом нужно уметь пользоваться. Высказывания навроде "этот инструмент плох, потому что я не умею им пользоваться" или "этот инструмент плох, потому что многие не умеют им пользоваться" просто смешны. |
Автор: nornad 14.7.2007, 15:58 | ||
Тот же камень можно бросить и в ваш огород, сэр. ![]() В качестве примера полезности вариации ВН можно привести всё ту же статью и предложение y3u по использованию не сокращений, а полновесных слов в имени переменной. |
Автор: goodday1941 14.7.2007, 17:03 |
эм.. что это? ![]() |
Автор: y3u 14.7.2007, 18:13 |
http://justfuckinggoogleit.com/search.pl?query=checked+exceptions |
Автор: goodday1941 14.7.2007, 21:30 | ||
а ссылочка битая однако ![]() ![]() |
Автор: y3u 14.7.2007, 21:53 |
где это она битая... читать надо что там пишут, внимательно причем... через 15 секунд все появилось бы |
Автор: w1nd 16.7.2007, 07:07 |
Нельзя ![]() ![]() |