От модератора:

Ребята, давайте жить дружно. Если еще раз увижу такой разнос в основном форуме - ругачки не по теме, картинки сомнительного содержания и прочий флуд, буду удалять. Это первое и последнее предупреждение. Не забываем, что это основной форум. Поболтать - в Курилку, личные разборки - в ЛС.





Исправлено 5 раз(а). Последнее : Божья_коровка, 28.11.20 18:52

Simple777
В конце концов в VFP в интерактивной среде есть кнопка "сделать п..дато" - мечта любого фотожабера.

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

Simple777
Например, встречал такой подход - все имена полей начинаются с буквы Q. Сам такой подход не использую, но общался с разрабом, утверждавшим, что это очень удобно.

Было у нас такое принято - но слава богу осталось лишь в Клиппере, ну частично проникло в другие среды там где были какие-то "связки-выгрузки". Лично меня это бесило всегда. Уточнение при помощи алиаса (в т.ч. префикс m. для переменных) - вот надёжный, прямой и правильный способ разделять переменные и имена полей. А не надуманные Q, и "веселуха" после не менее любимых SCATTER, когда уже и переменные начинаются с этой же буквы.
Кстати, для VFP я бы рекомендовал максимально ограничить использование "SCATTER MEMVAR" - в пользу других его вариантов.

Simple777
Что же касаемо всяческих отступов при написании кода и уж тем более для SELECT SQL, то это уже явный перебор, мтк.

Вовсе нет. Это очень важная штука - НО надо исходить из имеющегося функционала автоформатирования в IDE. Нет ничего хуже смеси пробелов и табуляций разного размера при мало-мальской "совместной" работе с кодом. И уж во всей красе это вылазит при использовании систем контроля версий. Бесят коммиты где на пару изменённых строк приходится ещё 150 изменений в самых разных файлах в части отступов и т.п.

Taran
В том числе мюиспользование прописных/строчных букв...Но! Может быть ситуация когда файлы лежат на Unix типа сервере.

И системы контроля версий по умолчанию регистрочувствительны к именам файлов, так что это всегда очень важно.

Ydin
Например, "Автор программы - ...". В коллективе программистов - к кому обратиться, с кого взыскать..
Назначение модуля - да сам забудешь, если свой. А для других тем более.

Авторов может быть куча, при том тех кто это изначально писал, уже давным давно может и не быть в зоне доступа. Система контроля версий позволяет при необходимости отследить каждую отдельную правку, показать автора каждой строки, вкупе с описанием коммитов (если их не ленятся делать) это позволяет понять и мотивацию каждого изменения.
"Назначение модуля" должно быть на 99% понятно по его названию. В описании могут быть какие-то нюансы, или "советы по правильному использованию" - но это на любителя (есть масса проектов где лучшей документацией является сам код. Есть и такая мысль - если код нуждается в пояснениях, то его надо переписать так, чтобы никаких "пояснений" для его понимания более не требовалось). Есть подходы где документация находится отдельно от собственно кода (особенно сли предметная область сложна, и без хорошей вне-программистской подготовки понять что к чему - проблематично).

PaulWist
что бы знать историю изменения.

Для этого есть системы контроля версий.
Нет ничего хуже простыни кода, где на 10 команд будет 30 строк комментариев, расписывающих кто, когда и зачем некоторое изменение сделал. И да, СКВ широко используются уже дай бог лет 20 как, так что "доисторические" приёмы впихивания всей истории разработки в сам исходник это очевидный моветон. Даже безотносительно к актуальности используемого языка/системы программирования.

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

Ровнять то можно - но только если будет инструмент который это автоматически сделает. Заставлять разраба заниматься "правильными отступами" - глупо и вредно.

Igor Korolyov

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

Ровнять то можно - но только если будет инструмент который это автоматически сделает. Заставлять разраба заниматься "правильными отступами" - глупо и вредно.

А зачем "можно" если это вредно. Читать то начинаешь слева. И рыскать глазами на пару-пять символов влево вправо ни к чему чтобы найти ту или иную секцию.
При нажатии Ентер курсор встаёт куда надо, в начало предыдущей строки. Все. Достаточно инструментов.
Ровный правый край никогда ни в каком из вращении не может быть полезен.

Taran
А зачем "можно" если это вредно.

Это не вредно - это полезно. Но фокс из коробки может лишь очень и очень ограниченно форматировать исходник.
Для примера посмотри как форматируются исходники на других языках. Как правило синтаксические конструкции делаются с отступом, отдельные команды, если они слишком длинные для одной строки, тоже "продолжаются" с отступом. И в более-менее "богатых" IDE есть огромное количество настроек, плюс механизмы сохранения этих самых настроек (чтобы любой разработчик работающий с проектом автоматом использовал эти самые настройки, и даже помимо своего желания соблюдал утверждённый стиль кода).
Среди "стилей" есть самые разные, включая и выравнивание ключевых слов SQL запроса по их правому краю, разные варианты выравнивания списка полей, условий, соединений, и т.п.
Вообще смысл любого стиля (и прочих соглашений - по именам и т.п.) в том чтобы код был максимально единообразно оформлен - чтобы глаза не разбегались и мозг не закипал при переходе от одного файла к другому. И чтобы при изменении кода этот стиль сохранятся, и не было "войны стилей форматирования" - когда каждый разработчик переиначивает код по своему - то пробелами отступ, то табами, то по 2 пробела, то по 4 или вообще по 8, то заглавными команды, то строчными...
При этом, конечно же, нет и не может быть "единственно верного" стиля оформления - это всегда субъективный вопрос, вкусовщина.

Это все понятно.

Я про единственное хотел сказать:
Нет смысла выравнивать ключевые слова в начале строк по правому краю.

Это есть как минимум в 2 популярных системах (может и больше где) в Toad от Quest Software и в Sql Developer от Oracle. Т.е. это уж абсолютно точно не то что "никому не нужно" - вполне востребованная фишка форматирования SQL кода. Конечно, она может кому-то не нравится, ну так я и говорю что все стилистические вопросы - это вопросы вкуса, о которых спорить смысла нет

www.thatjeffsmith.com

Цитата:

Due to popular demand

значится "по просьбам трудящихся" добавили
А вот диалог настройки второго - там примерно видно как именно будет форматировать.
[attachment 34291 toad_oracle_formatter.png]

Конечно "востребованная". Она и здесь была озвучена сразу при постановке.
Но она неправильная.
Конечно о вкусах не спорят в отличии от целесообразности. ;)

Igor Korolyov

PaulWist
что бы знать историю изменения.

Для этого есть системы контроля версий.
Нет ничего хуже простыни кода, где на 10 команд будет 30 строк комментариев, расписывающих кто, когда и зачем некоторое изменение сделал. И да, СКВ широко используются уже дай бог лет 20 как, так что "доисторические" приёмы впихивания всей истории разработки в сам исходник это очевидный моветон. Даже безотносительно к актуальности используемого языка/системы программирования.

Ну да, ну да

Мне сейчас приходится поддерживать проект 25-летней давности, в "четвертой" команде "писателей" (а команды по 15-20 нетленщиков), версий только в "четвертой команде" уже почти 2000, документацию хоть и пытаются поддерживать, но она уже занимает десятки Мб, это первое.

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

PS как говорится, кто о чём, а вшивый о бане (это я про себя, если что) ;)

PaulWist
PS как говорится, кто о чём, а вшивый о бане (это я про себя, если что) ;)

Наверное, за редкими исключениями, это самое верное изречение для всей этой темы.

Паша, внешняя документация нужна НЕ для понимания кода, а для понимания бизнес-процессов, требований к софту, дизайну форм, в общем к предметной области.
Внутри кода "документация" если и будет, то это будет формализованная документация АПИ (при том она пишется используя специальные соглашения, позволяющие автоматизированным системам собирать из этого внешние файлы описания АПИ). Как правило этим заморачиваются при создании отчуждаемых или очень сильно переиспользуемых компонент - то что по сути является "системной" а не прикладной частью. Большинство библиотек/компонент, как свободных так и коммерческих, именно по такому принципу делаются.

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

Сначала в доки - если я не понимаю что это за функционал, и как он должен работать. Естественно в само "требование по модификации", где как правило описывается "как надо", или для багов - "что и когда не работает". Потом уже в код - и я тебя уверяю, никакие ремарки типа "// Вася: Тут была проблема с високосным годом, мы с Саней решили что надо добавить 0.5 к сумме" мне не помогут, да и в 99.9% случаев такового в коде НЕ БУДЕТ.
Вообще "идеальный код" должен читаться как собственно описание решаемой задачи, и не требовать пояснений к своей сути.

В коде оставляют todo, ремарки о том что "это оптимизация", потому не надо тут 'улучшать', ну или как минимум надо ознакомится с мотивацией для этой самой оптимизации. Но саму мотивацию к изменениям, или авторство того или иного кусочка кода - нет.

В историю изменений я загляну лишь в крайнем случае, если мне покажется совсем уж неочевидным что-то, или если возникнет обоснованное подозрение что раньше этот код работал иначе, и надо будет уточнить когда и зачем его изменяли.
В промышленной разработке код всегда связан с системой контроля версий, а она в свою очередь - с системой управления проектом (багтрекер, доска с задачами) - поэтому обычно есть возможность для каждого изменения выйти на ту "карточку", в которой описывалось для чего это надо и как оно должно работать.
Ты же не ожидаешь увидеть в исходнике картинки отчётных форм, какие-то экселевские или вордовские документы с описанием методологии расчётов, банально переписку разработчиков с BA, PO, QA по поводу некоторой реализованной функциональности
Код - это код. Прочие проектные артефакты - это прочее, и не надо всё в кучу сваливать.

lulgu

sphinx
Все же по существу лучше.

Так никто же тебя не заставляет трындежом заниматься, здесь не курилка.
Набери в Хелпе Select и учитесь на пару с Тараном селекты писать.
Выпиши оттуда примеры и составь себе небольшой FAQ на все случаи жизни.
С SET-настройками вместо вечных словоизлияний напиши процедуру, хоть польза для общества будет.
Вместо бессмертного Максимовского стартового файла посмотри в wizards/framework.vcx как goApp пишется.

Посмотрел. Там что-то НИ СТРОЧКИ про соглашения о языке.
И еще. Я тебе не грубил, трындежом именно в этой теме не занимаюсь - посильно помогаю.
Или пытаюсь помочь коллегам.
Я тебя чем-то обидел? Если да - напомни, может я правда виноват.

Igor Korolyov
Было у нас такое принято - но слава богу осталось лишь в Клиппере

Ого! Ты еще и на Клиппере писал! Коллеги.

PaulWist
Мне сейчас приходится поддерживать проект 25-летней давности, в "четвертой" команде "писателей" (а команды по 15-20 нетленщиков)

+100500

Моя любимая присказка - "Я не знаю, как ДО меня, как у вас, а у меня работать будет".
С 1995 года наворотили г-кода в ненормализованных базах - заметь, не я. Когда пришел - одни слезы были, теперь очень редко звонят. Ну понятно, из ненормализованных данных сделать непадающее (от поступаемых данных) - нереально.

Раз в год - неплохо, считаю. Нормализуем - вряд ли упадет вообще, я и коллеги дело знаем.





Исправлено 1 раз(а). Последнее : sphinx, 28.11.20 20:13

Ydin
Лулгу вроде хотел помочь, чего спешишь

sphinx
Документ еще не подписан, что-то можно подправить

Молодежь подоспела, придержи лошадей.
Свежие мысли у ворот.
Английские буквы подождут.

Саня, есть время, согласен. Еще на работе будем обсуждать... Мысли будут, уверен. Не все подтянулись.