LINUX.ORG.RU

Рабочий стол программера


0

0

Вот я все смотрел на чужие скриншоты, где была показана разработка программ и все думал, почему окна с кодом загнаны в угол, а остальное место занимают всякие программульки? Мне, например, места всегда не хватает. Хочеться, чтобы экран был размером со стол.

Итак, здесь у нас Fedora Core 1 (в скорости собираюсь перехать на FC3), ядро 2.6.7 (я не любитель качать ядра на следующий день после выхода очередной версии, то что есть меня устраивает и про количество дыр в нем я знаю, но моя машина не смотрит напрямую в Internet), Enlightenment 0.16 компилировал сам с помощью rpmbuild, NetBeans IDE 3.6 (я знаю, что уже есть версия 4.1, но заменю свою на более старшую тогда, когда возникнет реальная необходимость), на другом столе Firefox 1.0 с JavaDocs, которые хранятся на локальном Web-сервере (мне так удобно). Последний использует порт 81, потому что на порту 80 висит Tomcat, для которого и разрабатывается приложение.

Прошу прощения за jpeg, но png не помещался в отведенные 300 Кб, а в оптимизации изображений я не сильно разбираюсь поэтому, что получилось, то и положил.

Что же касается обилия комментариев, то я всегда их пишу в таком количестве и никогда от этого не страдал. Наоборот много комментариев помогают мне писать код и затем ориентироваться в нем (те кто писал более 1000 строк на ассемблере меня поймут).

Размер окна NetBeans IDE проводит линию в 90 символов в строке, за которую я стараюсь не заступать при оформлении кода. То что на фон попал XMMS чистая случайность, а не желание положить стандартный XMMS со стандартным скином в скринтшот.

Вообщем критикуйте.

>>> Просмотр (1152x864, 261 Kb)

anonymous

Проверено: Shaman007 ()

А конечно не имею ничего против великого и могучего, но комментарии писать на русском - это клиника.

human0id ★★★
()
Ответ на: комментарий от Demetrio

>а не голых баб на десктоп прикручивает ;)

а я и не прикручивал :p

U-ZvER
()

Действительно похоже на рабочую обстановку. Лично я предпочитаю держать 3 (иногда 4) десктопа. На одно на весь экран развернут редактор (в моем случае vim) на другом - доки. А музыка и чат уже на 3ем и 4ом.

Коментариев много не бывает! Особенно, когда они в формате javadoc (у меня doxygen) написаны!

Кстати, советую попробовать новый NetBeans. Мне он показался заметно быстрее. Кроме того вроде туда че то новенькое на предмет J2EE добавили.

svyatogor ★★★★★
()

Документация в JavaDocs ihbanjv Times - это ЗЛО (как тут любят говорить). Кто пользует MSDN меня поймет.

macavity
()

Нормальная рабочаю обстановка, слегка, правда, сдобренная Enlightenment-ом.. по поводу комментариев - молодец, никогда лишними не бывают, особенно, если года этак через два возвращаешься к своему же коду, и с первого взгляда впадаешь в недоумение, навроде - "опаньки! млин,.. а что это вообще такое?" тут то тебе и комментарии в помощь, не говоря уже о других людях, которых угораздит в этот код забрести.. а вот Nightwish - попса, не советую такое слушать, музыкальный вкус испортишь..

MiracleMan ★★★★★
()

Можно поинтересоваться NetBeans не тормозит(Swing - как не как)? Просто как-то ставил себе это чюдо ~3.6 на Athlon-XP 2000+; рамы было мало но в своп не уходило и тормозило дико(Gentoo Linux - все нормально собрано) Друг пробывал P4 / 256Мб / WindowsXP тормозит дико.

Как у вас ,нормально? Если да , то какое железо ему надо?

Чем не устраевает Eclipse(я новичек в Java, знаю не много)?

anonymous
()
Ответ на: комментарий от sakura-obscura

Процессор PIV 1.8 Гц, ОЗУ 256Мб, Video GeForce 2 MX400 64Мб (X-Server конечно от NVidia), swap 512 Мб, но я стараюсь делать так, чтобы Linux в swap не попадал, поэтому в каждый конкретный момент времени загружено столько программ, сколько нужно для работы.

anonymous
()
Ответ на: комментарий от svyatogor

Новый NetBeans я попробовал. Работает действительно быстрее. Хотя и 3.6 не тормозил. По крайней мере у меня.

anonymous
()
Ответ на: комментарий от anonymous

NetBeans не тормозит. Вполне нормально работает. Кстати, под Windows у меня тоже работает неплохо, я пробовал.

anonymous
()
Ответ на: комментарий от anonymous

NetBeans мне нравится тем, что в нем отсуствуют всякие мастера (ну почти отсутствуют). Я все предпочитаю делать руками, вплоть до конструирования GUI и описания обработчиков событий. NetBeans в этом не мешает. А такие полезные штуки, как автоподстановка имен классов и методов и автоматическая генерация javadoc по моим методам и классам приятно ускоряют процесс разработки.

Если рассматривать с этой точки зрения, то NetBeans'a вполне хватает, а другие супер навороченные оболочки только тормозят систему и ничего дополнительного мне предложить не могут.

anonymous
()
Ответ на: комментарий от MiracleMan

> не согласен.. MSDN - msdn-ом,.. а JavaDocs с Java удобен, а значит и использованию подлежит..

Я говорил не о том, что не подлежит, а о том, что шрифт Times для документации - это плохо.

macavity
()
Ответ на: комментарий от anonymous

А как в NetBeans дела с рефакторингом? Помню в третьей версии у них с этим вообще беда была.

anonymous
()
Ответ на: комментарий от anonymous

В NetBeans 4.0 появился. Но подробно не смотрел еще.

anonymous
()

Ужас! Комментировать очевидные вызовы! А там среди текста хоть код есть? Имена функций должны объяснять код, но не комментарии к ним.

anonymous
()
Ответ на: комментарий от macavity

знаешь, на мой взгляд шрифт годится, для меня, разумеется, в последнее время вообще шрифты замечательнуе пошли, не то что году этак в 1993-ем где-то... просто дело в том, что я не избалован всем этом дизайнерским напылением.. для меня большее значение имеет наполнение, а не дизайнерское испонение, хотя иногда и то приятно.. а ты то сам чем собчтвенно занимаешься? ;-)

MiracleMan ★★★★★
()
Ответ на: комментарий от MiracleMan

> это для тебя они очевидны! а для поколений? для других? может кто и не > знает о том, для того и коментарии..

Комментарии устаревают гораздо быстрее, чем предполагает их создатель... В данном случае из всего этого потока жавадока ценно одно слово: IMAP4. Все остальное более-менее грамотный программист поймет из названия метода и названий параметров. Еслиб метод назывался createIMAPInboxConnection, даже это единственное ценное слово не понадобилось бы.

Nageneril_Mudrapragram
()
Ответ на: комментарий от Nageneril_Mudrapragram

>Комментарии устаревают гораздо быстрее, чем предполагает их создатель..

не уверен в этом, склонен не согласится с подобной точкой зрения..

>В данном случае из всего этого потока жавадока ценно одно слово: IMAP4. Все остальное более-менее грамотный программист поймет из названия метода и названий параметров. Еслиб метод назывался createIMAPInboxConnection, даже это единственное ценное слово не понадобилось бы.

понимаешь, возможно, именно в данном контексте твои слова и справедливы, но я то имел в виду более общее определение, помятуя ещё те времена, когда разработчики были вовсе не склонны давать методам очевидные названия.. (а некоторые и сейчас к этому не склонны) и, к тому же, в любом случае, привычка оставлять исчёрпывающие комментарии по определению своей работы, далеко не самая худшая привычка из всех возможных,.. скорее наоборот.. ;-)

MiracleMan ★★★★★
()

гыг, а все туда же, "моя программер!" Ж))

anonymous
()
Ответ на: комментарий от MiracleMan

> а ты то сам чем собчтвенно занимаешься? ;-)

В смысле?

anonymous
()
Ответ на: комментарий от Nageneril_Mudrapragram

> Комментарии устаревают гораздо быстрее, чем предполагает их создатель...

По моему это говорит только об одном. Автор сообщения предпочитает изменять код не документируя изменения. Тогда и получается, что со временем комментарии конечно же устаревают. Я всегда пишу код с комментариями, которые отражают реалии. Если изменяю код, изменяю и комментарии к нему.

> В данном случае из всего этого потока жавадока ценно одно слово: IMAP4.

А Вы когда разрабатываете программы по памяти помните назначение всех параметров методов и набор генерируемых исключений? А так же что последние означают?

Мне же NetBeans любезно предоставляет javadoc документацию к функции, когда я к ней обращаюсь в программе. И мне не нужно напрягаться и вспоминать, а что означает такой-то параметр или генерация исключения, я просто читаю это в выпадающем окне. На мой взгляд от этого качество кода только повышается.

anonymous
()

> @throw AuthentactionFailedException не пройдена авторизация на сервере

Уважаемый анонимус, запостивший скрин, да будет вам известно, что: 1. AuthentIcation. И почему в комментах название эксепшена написано неправильно, а в самом коде - правильно? 2. Аутентификация != авторизация.

ezhi
()
Ответ на: комментарий от anonymous

набор генерируемых исключений "помнит" eclipse. Вы бы еще переводы строк комментировали....

anonymous
()
Ответ на: комментарий от anonymous

>набор генерируемых исключений "помнит" eclipse. Вы бы еще переводы строк комментировали....

А также то, что IllegalStateException вылетит, если соединение уже есть?

А по поводу очевидных названий - попробуйте разобраться в Xerces-C, мне пришлось по ней ходить отладчиком, чтобы выяснить, где она в XSModel складывает информацию о типах.

А вот Qt не надо отладчиком мучить, если только глюки искать. Правда, глядя на комментарии в исходниках кажется, что книгу пишут, а исходник на C++ - это так, рядом тут прилагается...

adarovsky ★★★★
()
Ответ на: комментарий от MiracleMan

> имел в виду более общее определение, помятуя ещё те времена, когда разработчики были вовсе не склонны давать методам очевидные названия.. (а некоторые и сейчас к этому не склонны)

> привычка оставлять исчёрпывающие комментарии по определению своей работы, далеко не самая худшая привычка из всех возможных

Мнээээ, если комментируется то, что и так очевидно, то это попросту дублирование информации. Со всеми вытекающими из этого неприятностями: во-первых, тратится в два раза больше времени, во-вторых, дублированную информацию надо синхронизировать, что опять же есть потеря времени и возможность когда-нибудь получить несогласованное состояние. Так как код врать не может, то значит будет врать документация. А документация, которая врет, хуже той, которой нет.

Если комментируется то, что не очевидно (в нашем примере слово IMAP и IllegalStateException, который выбрасывается в случае наличий коннекции), то надо задуматься над тем, а нельзя ли сделать рефакторинг и превратить в очевидное то, что захотелось прокомментировать. Например, выбрасывать не IllegalStateException, а какой-нибудь AlreadyConnectedException.

Nageneril_Mudrapragram
()
Ответ на: комментарий от anonymous

> Автор сообщения предпочитает изменять код не документируя изменения. Тогда и получается, что со временем комментарии конечно же устаревают. Я всегда пишу код с комментариями, которые отражают реалии. Если изменяю код, изменяю и комментарии к нему.

Автор сообщения изменяет код *не боясь* что забудет изменить документацию. И документирует изменения в системе контроля версий :) А вы, возможно, тратите впустую немало времени, за которое могли бы написать еще много полезного кода.

> А Вы когда разрабатываете программы по памяти помните назначение всех параметров методов и набор генерируемых исключений? А так же что последние означают?

Нет, не помню :( Но мне Eclipse любезно предоставляет список методов класса и список параметров метода, вместе с названиями. И по их именам и типам, если они грамотные, я понимаю, что от меня ожидают. А те exception'ы, которые мне надо ловить, Eclipse тоже услужливо отмечает. И предлагает либо швырнуть дальше, либо поймать. Слово "Eclipse" можно заменить на слово "IntelliJ IDEA", если угодно.

Nageneril_Mudrapragram
()
Ответ на: комментарий от MiracleMan

> это для тебя они очевидны! а для поколений? для других? может кто и не знает о том, для того и коментарии..

Если для кого-то неочевидно store.connect = подключились то за програмирование таким гениям лучше не садиться.

anonymous
()
Ответ на: комментарий от adarovsky

> А вот Qt не надо отладчиком мучить, если только глюки искать. Правда, глядя на комментарии в исходниках кажется, что книгу пишут, а исходник на C++ - это так, рядом тут прилагается...

Как раз они пишут нормально. Код они практически не комментируют зато делают включения для doxygen документации. А комментировать код в Qt нет смысла - все имена вызовов прекрасно обьясняют код, API проработана чудесно. А то что doxygen дока прямо в коде - так способа как лучше документировать вызовы и сохранять их соответствующим коду лучший вариант.

anonymous
()

Тут, конечно же, никто не выступает за отмену комментариев и документации вообще. Но зачем делать лишнюю работу, повторять самого себя и писать по два раза очевидные вещи? Особенно в package local методах (они ведь наверняка никому, кроме самого автора, и не нужны). Лучше за это же время написать несколько unit тестов, которые будут гораздо более полезными для повышения качества кода и для понимая другими происходящих процессов.

Nageneril_Mudrapragram
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.