[MaratZuev 0]

Ну наконец-то пошли комменты по делу. Огромное спасибо двум последним комментаторам.

[sorok-odin 5]

Если под правилами кодирования понимать в основном отступы и переносы (как вариации K&R/GNU/Linux/... у программистов), для бедных энтузиастов есть открытый проект https://github.com/jeremiah-c-leary/vhdl-style-guide . Недавно из любопытства попробовал его активировать в составе шикарного TerosHDL плагина к VSCode. Вроде интересная штука, гибко настраивается, много всего умеет. Проверяет код на соответствие куче правил форматирования, но не только. Например, на моем проекте ругается на присваивания при описании сигналов (типа "signal wr_en : std_logic := '0';"). И если подумать, логика в этом есть. Значения по умолчанию желательно устанавливать от сигнала сброса, а до этого в моделировании видеть их как 'Х' или 'U', иначе когда-нибудь можно выстрелить себе в ногу.

 

Жаль, нет обоснования правил, или я сходу не нашел. Приходится домыслы домысливать.

 

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

[warrior-2001 0]

15 часов назад, MaratZuev сказал:

К нам не применимо: после покупки Сименсом Ментора последний стал для нас недосягаем.

Я уже писал по этому поводу на форуме - для меня формально ни Ментор ни Сименс никогда и не могли быть доступными!

Однако всё легально куплено и работает.

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

У многих компаний РФ, связанных с работами в интересах МО, установлены продукты Сименса. И ничего, все работают и все довольны.

[MaratZuev 0]

6 minutes ago, warrior-2001 said:

Я уже писал по этому поводу на форуме

Я уже читал это на форуме и там же отвечал (про ненужные нам контакты тоже): предлагаю сказку про белого бычка не рассказывать. Хотя, раз вы такой настойчивый, ответьте (ещё раз): у вас есть ОФИЦИАЛЬНАЯ бумага, что вы ОФИЦИАЛЬНО купили ПО именно на ВАШУ ОРГАНИЗАЦИЮ? Если ответ НЕТ - давайте закроем этот нам не нужный гештальт. Если ответ ДА - давайте продолжим.

[warrior-2001 0]

 

55 минут назад, MaratZuev сказал:

у вас есть ОФИЦИАЛЬНАЯ бумага, что вы ОФИЦИАЛЬНО купили ПО именно на ВАШУ ОРГАНИЗАЦИЮ? Если ответ НЕТ - давайте закроем этот нам не нужный гештальт. Если ответ ДА - давайте продолжим.

Конечно есть. И бумага и лицензия и поддержка. У нас развёрнут сквозной маршрут проектирования, связывающий САПР разных вендоров. И все лицензии имеются.

Но раз вам это не нужно, то мне - и подавно.

Я просто не помню уже, кому отвечал. Раз это были вы - то вопрос снимается.

По теме могу добавить лишь то, что в своё время Altera тоже предлагала помощь в разработке и сертификации согласно DO-254 под свои ПЛИС. Но было это всё на предыдущем моём месте работы.

Сейчас мне сертификация не интересна.

По поводу правил - на многих предприятиях есть собственные СТо и СТП. Взяв несколько штук я собрал для себя то, что хотел и придерживаюсь данных правил. И всех своих коллег подсадил на это дело добровольно-принудительно.

Результатом доволен.

Изменено 9 ноября, 2021 пользователем warrior-2001
Дополнил текст.

[MaratZuev 0]

24 minutes ago, warrior-2001 said:

Раз это были вы - то вопрос снимается.

Л- Логика. Спасибо и на этом. Если это было здесь, то ваш пост проглядел. Приношу за то свои извинения.

[Longiel 2]

С одной стороны вроде бы понятно, что хочется снижения издержек переключения со своей работы на чужую. Но вот если взять свой пример... За много лет я выработал свой некий стандарт написания кода. Я жестко придерживаюсь своих шаблонов, сделал редизайн многих модулей, привёл важные вещи к своему субъективному стандарту красоты. И вот, что-то случается. Час Х настал. И надо чтобы он прошёл как можно быстро. Открываешь свой код годовой давности и... ничему этот стандарт не помогает) Сначала лазишь по этому коду порой как не по своему, так как уже всё забылось. Потом ищешь описание\схему прошивки, если есть - описание\схемы модулей. Разбираешься как это должно работать функционально. Далее или аналитически выявляется узкое\подозрительное место, или с пониманием встраиваешь отладчик и "разбираешься" с ситуацией. Многие вещи в последнее время решаются именно аналитически. Но для аналитического анализа важна не красота кода, а больше красота архитектуры. Вот и получается, что при наличии априорного знания функциональности разбираться в своём или чудом коде - мне без разницы. А если этого знания нет, то что свой трёхлетний код, что вчерашний чужой - мне особо и не принципиально. Я помню в один модуль "по наследству" стабильно лазил раз в 4-6 месяцев. Стиль кода уже давно не помеха. Но он был написан так, что... через 2 года я написал свой модуль с аналогичным функционалом и структурную схему для него сделал)

Поэтому если реально есть время\возможности, то надо требовать от программистов сдавать не сам-по-себе красивый код, а синтезируемый код - в процессе синтеза любая САПР сама подскажет, если есть синтаксические ошибки. Ошибки могут быть и это нормально, если человека постоянно отвлекают или он тянет несколько проектов сразу. А лишнее время путь лучше оформляют программную документацию. Причём подробные схемы сложных модулей или алгоритмов гораздо сильнее помогают что-то понять, чем десятки страниц исписанного текста. Почему-то ни у кого не возникает вопрос что схема топ-уровня прошивки - это однозначно полезная вещь, а вот в отношении отдельных модулей этой прошивки уже такого энтузиазма не наблюдается. Но на это да, надо выделять время, причём много времени - временная "стоимость" проектов просто тупо вырастет. А это плохо. Гораздо ж проще заставить всех оформлять код одинаково, считая что это каким-то волшебным образом поможет в будущем.

Изменено 27 ноября, 2021 пользователем Longiel

[MaratZuev 0]

11 hours ago, Longiel said:

Почему-то ни у кого не возникает вопрос что схема топ-уровня прошивки - это однозначно полезная вещь

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

11 hours ago, Longiel said:

Но вот если взять свой пример...

Скажите: в вашей организации Э3 разводят кто где хочет, не придерживаясь никаких ГОСТов и прочего? Или вы вообще на аутсорсе работаете. И да, если у вас только вы один разработчик, то вопросов нет, в противном же случае. Мы сто лет жили как вы описываете, пришло время причёсывать мешанину. Я, как ТС, говорю о стандартизации, и все, включая вашу, попытку дезориентировать меня заранее обречены на полнейший провал (с) Е. Летов.

[Longiel 2]

9 часов назад, MaratZuev сказал:

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

Какой схемой? В Visio??? Во втором абзаце я предлагаю ПД нормальное делать, а не модули в схематике отрисовывать...

9 часов назад, MaratZuev сказал:

И да, если у вас только вы один разработчик, то вопросов нет, в противном же случае. Мы сто лет жили как вы описываете, пришло время причёсывать мешанину.

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

[Gorby 6]

Мишку мучает вопрос - кто здесь враг таинственный?
А ответ ужасно прост, и ответ - единственный…(с)

Самый опасный вид чудака- чудак с инициативой…

Если что, намерения обидеть никого не имел. 

[makc 192]

40 минут назад, Gorby сказал:

Самый опасный вид чудака- чудак с инициативой…

Чудак без инициативный тоже опасен, но по-другому. Вопрос в том, как организовать разработку, чтобы человеческие качества ("чудачества") в меньшей степени оказывали влияние на результат, но при этом не ограничивали творческую свободу. Взять тот же ГОСТ 2.001-2013 и его п.п.4.2:

Цитата

Основное назначение стандартов ЕСКД состоит в установлении единых оптимальных правил, требований и норм выполнения, оформления и обращения конструкторской документации, которые обеспечивают:

- применение современных методов и средств при реализации процессов ЖЦ изделия;

- взаимообмен конструкторской документацией без ее переоформления;

- безбумажное представление информации и использование электронной цифровой подписи;

- необходимую комплектность конструкторской документации;

- автоматизацию обработки КД и содержащейся в них информации;

- высокое качество изделий;

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

- расширение унификации и стандартизации при проектировании изделий и разработке конструкторской документации;

- проведение сертификации изделий;

- сокращение сроков и снижение трудоемкости подготовки производства;

- правильную эксплуатацию изделий;

- оперативную подготовку документации для быстрой переналадки действующего производства;

- создание и ведение единой информационной базы;

- гармонизацию стандартов ЕСКД с международными стандартами (ИСО, МЭК) в области конструкторской документации;

- информационную поддержку ЖЦ изделия.

 

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

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

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

[MaratZuev 0]

27 minutes ago, makc said:

Я понимаю, наболело

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

Что насчёт правил: есть правило высказываться по существу, и тот, кто этого не делает, имеет полное право рассчитывать на адекватную реакцию.

За сим разрешите откланяться, и более не принимать участие в этом, мне не нужном обсуждении.