Автокомплит для быстрого добивания, документация для познания. Когда яХочуДописатьДлиннуюФункциюИ(вглянуть, порядок, аргументов), нахера мне лезть в документацию, чем она поможет? Ведь я ее _уже_ прочитал и знаю как работать с функцией/методом/етц.

тогда надо обеспечить очень быстрый поиск по документации

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

Нужно и то и другое. Без автокомплита тоже можно, но с ним намного удобнее. И еще автокомплит помогает избежать идиотских опечаток.

Автокомплит для быстрого добивания, документация для познания. Когда яХочуДописатьДлиннуюФункциюИ(вглянуть, порядок, аргументов), нахера мне лезть в документацию, чем она поможет? Ведь я ее _уже_ прочитал и знаю как работать с функцией/методом/етц.

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

тогда надо обеспечить очень быстрый поиск по документации

Быстрый поиск не такая уж проблема.

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

Тогда лучше тренировать память. Ну и в документации название тоже есть.

>Что бы посмотреть как она пишется. Ах да, если есть такая функция, то ее надо переименовать в более короткую и лаконичную, ну или если она в сторонней библиотеке, обернуть. К тому же если знаешь, то напечатать быстрее, правда для этого нужно в слепую печатать уметь.

И это столько волокиты только для того, чтобы не использовать автокомплит?

Нет, не быстрее

Пример

[NSA-> i->W->Z(a>>b&>&>; где -> - это клавиша автодополения

перехода к следующему placeholder'у

&> Переход вперед на уровень выше в скобочном выражении

Получиться [NSApplication initWithZone(a,b)];

Нужно и то и другое. Без автокомплита тоже можно, но с ним намного удобнее. И еще автокомплит помогает избежать идиотских опечаток.

Я же не говорю что автокомплит зло и давайте жечь спички. Он тоже бывает полезен. Меня интересует почему столько внимания уделяется именно автокомплиту, а не документации, которая куда более необходима.

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

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

> Меня интересует почему столько внимания уделяется именно автокомплиту, а не документации, которая куда более необходима.

Ну вроде компы еще не научились по коду генерить документацию.

И это столько волокиты только для того, чтобы не использовать автокомплит?

Волокиты? Длинные названия говорят о плохой декомпозиции задачи или плохом названии (чаще всего именно о плохом названии), а это уже проблемы проектирования. Печатать в слепую полезно даже с автокомплитом.

>Меня интересует почему столько внимания уделяется именно автокомплиту, а не документации, которая куда более необходима.

Видимо потому, что нормальный автокомплит далеко не везде сделан, и его нормальной работы не хватает. К тому-же документация просто _физически_ далеко не всегда есть. А по автокомплиту, построенному на данных интроспекции можно хоть что-то понять в сторонних блобах. К тому-же идеальный вариант - это когда и то и то вместе. Примерно так, как сделано в эклипсе для жабы.

> Волокиты? Длинные названия говорят о плохой декомпозиции задачи или плохом названии (чаще всего именно о плохом названии), а это уже проблемы проектирования.

Некоректное высказывание

newSomeObjectWithFromNamespaceWithArgType

или

Namespace::SomeObject::new::ArgType

Разницы не какой, просто во втором случае автокомлит может лучше сработать

Ну вроде компы еще не научились по коду генерить документацию.

Зачем что-то генерировать, достаточно предоставить удобный доступ к документации с поиском. К тому же по комментариям компы уже давно умеют генерировать документацию.

>Волокиты? Длинные названия говорят о плохой декомпозиции задачи или плохом названии (чаще всего именно о плохом названии), а это уже проблемы проектирования. Печатать в слепую полезно даже с автокомплитом.

У меня длинные названия часто говорят о том, что мне иногда лень придумывать сокращения и аббревиатуры для тех сущностей, которые описывает программа. Про слепопечатание я вам отдельно ответил где-то выше.

Видимо потому, что нормальный автокомплит далеко не везде сделан, и его нормальной работы не хватает. К тому-же документация просто _физически_ далеко не всегда есть. А по автокомплиту, построенному на данных интроспекции можно хоть что-то понять в сторонних блобах. К тому-же идеальный вариант - это когда и то и то вместе. Примерно так, как сделано в эклипсе для жабы.

Да, в эклипс это хорошо сделано, правда нормально это только с java работает. И опять же, много где документации и там нет, даже в библиотеках из sdk, и поиск там в ней какой-то странный.

А что щас неудобный? проблема в том, что коментируют мало код

Да и автокомплит пишут программисты IDE. А документацию - программисты бибилотеки

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

Мсье живет в идальном мире? Мсье никогда не сталкивался со сторонними кусками кода, которые рефакторить нет ни времени ни возможности? Мсье никогда не работал в крупных проектах где куча либ/компонентов сторонние и поставляются без исходников и документации? Мне вот лень например без автокомплита набивать метод типа: registerConsumableForMethodicOperationStep(String ctype, Integer stepState, Integer methodicState, Consumable cons)

void networkInfrastructure::registerPlugin

Вот например, наобум взятый метод. Автокомплит экономит мне несколько секунд на написание этого. А документация опишет, как с ним работать.

И вообще не понятен смысл холивора «автокомпил против доков», это совершенно разные вещи, применяемые для решения разных задач.

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

Смотря как работает автокомплит, если хорошо, то чаще всего быстрее, если есть задержки, то напечатать быстрее, да и ритм не теряется при этом.

>правда нормально это только с java работает

В том то и проблема, что для более интересных языков такую поддержку либо гораздо сложнее сделать (в случае динамических языков а-ля python||javascript) либо никто особо не заморачивается с ее написанием (Как например для скалы). Вот и приходится на жабке сидеть :(

>Смотря как работает автокомплит, если хорошо, то чаще всего быстрее, если есть задержки, то напечатать быстрее, да и ритм не теряется при этом.

Ну и к чему это? Не пользуйтесь плохим автокомплитом, делов то.

Некоректное высказывание

newSomeObjectWithFromNamespaceWithArgType

или

Namespace::SomeObject::new::ArgType

Разницы не какой, просто во втором случае автокомлит может лучше сработать

Наверное и про то что длина строчки кода не должна превышать 70 символов говорить не стоит.

В общем кто как любит, это вообще дело вкуса каждого программиста.

void networkInfrastructure::registerPlugin

А до void network::registerPlugin сократить нельзя?

И вообще не понятен смысл холивора «автокомпил против доков», это совершенно разные вещи, применяемые для решения разных задач

Ну это очень близкие задачи, и было бы хорошо если бы в IDE их подружили. Я к тому, что было бы приятно, что бы мне выдавались функции по описанию их работы, а не только по названию.

javadoc делает и то и другое. Там сразу в IDE всплывает подсказка, а ниже фрагмент документации.

>А до void network::registerPlugin сократить нельзя?

Нельзя. Это часть сетевого модуля программы, обеспечивающая базовую работу с сетью. В модуле и его соседях много чего еще, связанного с network, как в смысле именно сетевых протоколов и прочего, так и с тем, что сама программа оперирует в том числе сущностью «сеть». Данное название ИМХО наиболее отчетливо отражает суть.

Ну это очень близкие задачи, и было бы хорошо если бы в IDE их подружили. Я к тому, что было бы приятно, что бы мне выдавались функции по описанию их работы, а не только по названию.

Это совершенно разные задачи. Документация читается до разработки, в крайнем случае - во время, но никак не в перемешку с непосредственно написанием кода.

Это совершенно разные задачи. Документация читается до разработки, в крайнем случае - во время, но никак не в перемешку с непосредственно написанием кода.

Не поверишь, но я так и делаю, вперемешку с непосредственно написанием кода.

>Не поверишь, но я так и делаю, вперемешку с непосредственно написанием кода.

Не поверишь, я это понял еще в начале топика.

> Не поверишь, но я так и делаю, вперемешку с непосредственно написанием кода.

Как же вы пишите, если не знаете, с помощью чего пишите

>Длинные названия говорят о плохой декомпозиции задачи или плохом названии

Ага, creat()

>Как же вы пишите, если не знаете, с помощью чего пишите

Элементарно. Невозможно _твердо_ знать весь используемый апишник. Посчитайте хотя-бы сколько классов и методов в одной _стандартной_ библиотеке джавы или дотнетиненадо. Там и четверть то знать не реально. Можно только примерно понмнить что где должно лежать. Дальше юзаем автокомплит для просмотра методов и доку для конкретного описания.

>Документация читается до разработки, в крайнем случае - во время, но никак не в перемешку с непосредственно написанием кода.

Ага, конечно. Вот пишу я код. Надо мне вызвать someString.substring(beginIndex, endIndex); И вот хоть убей не помню я включатся в подстроку или нет символы с данными индексами. Быстро взглянул в доку по методу, выскочившему во всплывающем окне и поехал писать код дальше. Чем не пример чтения документации во время написания кода? И чем плох данный подход?

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

>Был бы не плох опциональный хинт мини-описания функции например по хоткею или еще как.

Ну в эклипсе для жабы так и сделано. При выборе метода из списка автокомплита для него показывается javadoc, если есть. По F2 переводим туда фокус.

Что конечно очень удобно, но фактически подсаживает на иглу жабосред. После их кучи удобств переходить на что-то еще очень сильно ломает. Я вот себя так и не заставил.

Ага, creat()

Вы наверное имеете ввиду create()? К тому же зачем как-то еще называть метод который что-то создает? Есть же перегрузка функций, и даже если ее нет, все равно имеется возможность реализовать разное поведение функции в разном контексте.

Потому что быдлокодерам лень читать документацию. Они предпочитают выбрать из менюшечки самую на вид подходящую функцию и не задумываться, что она делает на самом деле и насколько подходит к задаче.

а еще быдлокодеры пользуются быдло-IDE, которые в списке автодополнения показывают не только имя + тип, но еще и параметры + комментарии к методам и полям, быдлокодеры такие быдлокодеры

Она называлась именно creat(), погуглите, тут было недавно даже. Экономия же, 1 букву и то жалко :}

Она называлась именно creat(), погуглите, тут было недавно даже. Экономия же, 1 букву и то жалко :}

Зато как размер исходников уменьшается, лепота... :)

> быдлокодеры такие быдлокодеры

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

а у меня и то и другое одновременно

и твое метание между двумя ягодицами мне не ясно, а путь твой очевиден

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

у меня, например, код с картинками работает без исксов - я неправильный быдлокодер?

> я неправильный быдлокодер?

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

> А может быть, вы все-таки читали документацию

стыдно признаться - но было дело, сегодня вот всю ночь читал про особенности gcc, разбираясь почему корректный вызов dynamic_cast возвращает NULL( теперь ненавижу его авторов :) )

> корректный вызов dynamic_cast возвращает NULL

Неужели баг в Г++?!

> Неужели баг в Г++?!

угу, в их рассылке я нашел письмо за этот месяц с аналогичной проблемой и ответом, что эта проблема все еще решается

компиляторы с++ - это вообще феерия, недавно обходил баг msvc с кривым приведением типа для указателей на методы( на gcc все работало, это кстати оказался «популярный» баг msvc ), теперь наоборот - на msvc все работает идеально, а на gcc - нет