Стилі кодування при використанні декількох різних бібліотек

Я працюю над деяким кодом C ++, який використовує кілька бібліотек, включаючи деякі бібліотеки С, які мають різні стилі кодування. Він буде відкритий, коли він досягне стадії, що використовується. Що може викликати найменшу плутанину у короткочасного учасника, який перевіряє код, щоб виправити одну помилку або додати одну функцію?

• Майте один узгоджений стиль кодування у всій програмі, навіть якщо вона періодично не відповідає типовому стилю кодування використовуваних бібліотек.
• Коли бібліотека широко використовується в певному модулі, відповідайте типовому стилю кодування цієї бібліотеки (тобто стилю кодування, який використовується у власному коді та документації бібліотеки) цього модуля.

Думаю, що остання полегшить експертам у цій конкретній бібліотеці одноразовий внесок і полегшить включення підручника / прикладу коду під час розробки. Однак це також робить стиль кодування непослідовним у всій програмі. Які плюси і мінуси кожного підходу?

Я думаю, що це залежить від того, наскільки в цілому закінчиться проект.

Насамкінець, скажімо, у вас є проект на 1 Mloc. Для такого великого проекту малоймовірно, що жодна особа була б "експертом" у всіх задіяних областях. Тому в цьому випадку я б дотримувався існуючих стилів коду для кожного основного компонента. Нові розробники виберуть область, дізнаються про це, і навряд чи вони побачать багато інших компонентів, які можуть мати різні стилі коду.

Якщо проект набагато менший, де , ймовірно, люди зможуть зрозуміти всю базу коду, я б обрав домінуючий стиль коду і дотримувався цього. У цьому випадку я думаю, що послідовність у всьому проекті має більше сенсу, оскільки нові розробники, ймовірно, працюватимуть у всіх областях проекту.

Середньомасштабні проекти, мабуть, найскладніші для прийняття цього рішення. У цьому випадку ви повинні зважити витрати на кожен підхід і визначитися з тим, який, на вашу думку, буде найменш дорогим. Проблема полягає в тому, що середні проекти зазвичай виростають достатньою мірою там, де повне переробництво стилів виглядає непомірно дорогим. Ви можете по-другому переглянути структуру дерева кодових кодів, щоб побачити, чи можна впорядкувати об'єднання груп певних стилів коду разом.

Так чи інакше, остаточне рішення має залежати від команди, яку ви складаєте.

Деякі люди, які можуть змінити мої міркування згори:

• Якщо один або декілька модулів має жорстокий стиль, то немає сенсу зберігати це, навіть у більшому проекті. Так, стиль є суб'єктивним, але якщо вам та вашим колегам-учасникам проекту дуже не подобається те, як протікають певні ділянки, то занурюйте старий стиль і надайте йому кращий.

• Якщо всі стилі досить близькі один одному, може бути так само просто оголосити "ось новий шлях" і використовувати це для всіх нових кодів і значних рефакторинга. Це може викликати біль у відгуках, але, на мій досвід, більшість людей цілком здатні адаптуватися до цього підходу. Він також забезпечує контрольний знак, де знаходиться старий код.

• Іноді стиль зміщується на основі нових функціональних можливостей, доданих до мови. C ++ протягом багатьох років набрав ряд функцій. Можливо, має сенс переробляти за потреби старіший стиль на новий стиль, який використовує ці функції.

• Деякі бібліотеки можуть мати особливо ідіоматичний підхід або стиль. Якщо так, я б дотримувався цього стилю для цієї бібліотеки, навіть якщо це може суперечити решті проекту. Наміром тут є збільшити шанси на те, що той, хто працює frobnosticatorsнад іншими проектами, також буде працювати над вашим проектом.

У деяких коментарях згадуються імперативні та об'єктно-орієнтовані стилі як розгляд.

Модулі, які "важкі" у певному стилі, ймовірно, повинні залишатися таким чином, якщо модуль середнього розміру чи більше. Я працював з трьома основними стилями (імперативний, об'єктивний та функціональний), і перетворив важкі стилі імперативу на стиль ОО. З середньою або більшою кількістю коду, рефакторинг може бути (винятково) складним. Мій досвід був збентежений, тому що я не мав жодної підтримки інструментів, щоб допомогти в рефакторингу.

Я б міг уявити, що між сильно імперативно стилізованими модулями та тими модулями є ідіоматичні конкретні ніші розвитку, існує висока кореляція, яка повертається до останнього пункту, який я підняв з авангардами. Отже, будь-який модуль, який ви знайдете для цієї функціональності, буде виглядати так, і ви хочете, щоб фахівці цього домену могли легко працювати і над вашим проектом. Але якщо є варіанти, а вашій команді не подобається стиль цього модуля, я б дослідив варіанти.

Так само я працював з важким модулем в стилі OO, де принципи OO були взяті занадто далеко та використовувалися неправильно. Як приклад, інтерфейси використовувались як замінник багаторазового успадкування. І як ви могли очікувати, це було грубою реалізацією. Мені вдалося досягти розумного прогресу в рефакторингу цього модуля, але в кінцевому підсумку я відмовився від цього підходу, оскільки знайшов кращі пакети, які використовувати замість цього.

Здається, що слід враховувати кілька шарів, принаймні:

1. Існуючі бібліотеки та будь-які їх модифікації.
2. Новий тестовий код одиниці для цих бібліотек.
3. Шар абстракції.
4. API, представлений шаром абстракції.
5. Приклад і тестовий код за допомогою шару абстракції.

Я припускаю, що не має сенсу просто переробляти весь код на загальний стиль на передньому плані - якби це не було, ви б не ставили запитання.

Беручи кожен по черзі:

1. Для існуючої бази кодів ви, ймовірно, захочете дотримуватися цього стилю.
2. Новий тестовий код для існуючого коду стоїть у сірій зоні, особливо залежно від того, наскільки він інтегрований із старішим кодом. Але, швидше за все, я б спробував зробити це в «бажаному стилі».
3. Новий код у шарі абстракції. Переконуючись, що це дійсно окремий рівень коду, не повинно виникнути труднощів у використанні вподобаного стилю, навіть якщо код робить багато взаємозв'язків зі старим стилем або стилями. Більшість кодів потребує взаємодії з іншими стилями, і я ніколи не вважав це проблемою.
4. Очевидно, що сам API потребує найбільшої продуманості та задоволення максимальних потреб у користуванні.
5. Будь-який приклад або тестовий код також має бути спроможним писати у бажаному стилі. Залежно від повноти абстракції (тобто чи повністю приховує нижні шари), це може бути легким або складним. Звичайно, переконання, що майбутній код клієнта читабельний буде однією з ваших ключових цілей.

Деякі речі, які я особисто знайшов, - це те, що є велика база застарілих кодів:

• Встановлення бажаного стилю та застосування змін до коду не призводить до того, що весь старий код мігрує до нового стилю.

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

• Вимагаючи бажаного стилю у застарілій бібліотеці, як правило, виникає велика невідповідність стилю в цій бібліотеці. Так що для стандартів, які суто представлені навколо презентації, на відміну від надійності коду, важко також бачити велику користь у їх вимаганні.

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

Я погоджусь з @MetaFight тут, якщо ви розробляєте великий проект із великою кількістю сторонніх модулів.

Давайте зможемо зіставити свою проблему з проблемою реального слова: " Припустимо, у вас вдома тихий спосіб життя. Вам подобається, щоб у вашому місці було тихо, ви ніколи не розмовляєте голосніше і ніколи не любите жодного члена вашої родини. Але ви взаємодієте з багатьма різні люди на вулиці щодня приносять щось для вашого будинку. Не обов'язково вони також будуть говорити зниженим голосом, у такому випадку ви відповідно формуєте себе під час спілкування з такими людьми. Таким чином, інтерфейс або обгортка для цих людей є дуже гнучким лише заради Ваша робота буде виконана. "Тупий приклад ... lol

Але мій сенс - створити обгортку для таких бібліотек відповідно до їх стандарту кодування таким чином, щоб ви використовували ці бібліотеки через ці обгортки, підтримуючи свій оригінальний стиль кодування всередині.

+1 для MetaFight.

Очевидно, це призведе до найменшої плутанини, щоб використовувати єдиний стиль кодування протягом вашого проекту. Самий сенс використання стилю кодування в першу чергу полягає в тому, щоб полегшити читання та зміну коду.

Що стосується стилю коду, який використовується внутрішньо в бібліотеці, я не думаю, що це доречно. Якщо бібліотека занадто імперативна, то написання оболонки OO добре, але це не вимагає, щоб ви використовували той самий стиль коду, як у прикладах чи внутрішніх документах бібліотеки.