Як я повинен підготувати свій код для OpenSourcing та розміщення його на GitHub?


9

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

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

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

Я знаю, що ви завжди повинні все коментувати, і я буду вводити функцію @params для кожного методу, але чи є ще загальні поради?


Відповіді:


12
  • Переконайтеся, що в корені репозиторію є файл README.txt, який вказує людям інструкції щодо його побудови. Інструкції можуть бути у цьому файлі, або вони можуть бути в окремому файлі чи на вікі.
  • В ідеалі зробіть так, щоб ви могли повністю створити і протестувати код за допомогою однієї команди. Не потрібно купувати вручну кроків.
  • Переконайтеся, що у вас є тести на код. Це забезпечує зручне місце для інших розробників, щоб побачити, як використовується ваш код, а також він забезпечує мережу безпеки для людей, які змінюють ваш код. Знаючи, що я можу відредагувати ваш код, а потім запустити пакет, щоб побачити, чи я щось зламав, це безцінне.
  • Дотримуйтесь загальних стандартів кодування або публікуйте ті, які ви використовуєте.
  • Якщо ваш код використовує OO, переконайтеся, що принаймні всі публічні методи та атрибути мають достатню документацію
  • Переконайтеся, що зрозуміло, якою ліцензією використовується ваш код. Зазвичай це означає включити файл LICENSE.txt або дотримуватися механізму, який вимагає ваша конкретна ліцензія. Також зробіть свідомий вибір щодо ліцензії. Не використовуйте лише GPL, тому що це все, що ви знаєте. Крім того, не використовуйте лише BSD або MIT або Apache, якщо це все, що ви знайомі ... витрачайте годину на дослідження цих, щоб ви принаймні зрозуміли принципову різницю між ліцензіями GPL і не GPL.
  • Видаліть з коду всю конфіденційну інформацію, наприклад, жорстко закодовані імена користувачів, паролі, електронні адреси, ip-адреси, ключі API тощо (завдяки Хакану Дериалу за пропозицію)

Хороша порада. Також слід додати: Видаліть приватну інформацію, наприклад паролі / ключі api, якщо такі є.
Хакан Деріял

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

3

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

Спроба працювати над проектом лише з документацією на вихідний код завжди викликає неприємності.


1

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

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

Я знаю, що ви завжди повинні все коментувати, і я буду вводити функцію @params для кожного методу, але чи є ще загальні поради?

Прокоментувати все? Ні. Прокоментуйте той код, який справді потребує коментарів. Коментуйте скупо. Як потенційний користувач шмату коду, яку з наступних двох версій визначення класу ви б хотіли бачити?

Версія A:

class Foo {
private:
   SomeType some_name; //!< State machine state

public:
   ...

   /**
    * Get the some_name data member.
    * @return Value of the some_name data member.
    */
   SomeType get_some_name () const { return some_name; }

   ...
};

Версія B:

/**
 * A big long comment that describes the class. This class header comment is very
 * important, but also is the most overlooked. The class is not self-documenting.
 * Why is that class here? Your comments inside the class will say what individual parts
 * do, but not what the class as a whole does. For a class, the whole is, or should be,
 * greater than the parts. Do not forget to write this very important comment.
 */
class Foo {
private:

   /**
    * A big long comment that describes the variable. Just because the variable is
    * private doesn't mean you don't have to describe it. You might have getters and
    * setters for the variable, for example.
    */
   SomeType some_name;

public:
   ...

   // Getters and setters
   ...

   // Getter for some_name. Note that there is no setter.
   SomeType get_some_name () const { return some_name; }

   ...

};

У версії A я задокументував все - крім самого класу. Клас взагалі не є самодокументуванням. Коментарі, які є у версії А, абсолютно марні, або навіть гірші, ніж марні. Ось ключова проблема у ставленні "прокоментувати все". Цей невеликий лайливий коментар до члена приватних даних нічого не повідомляє, а коментарі доксигену щодо геттера мають негативне значення. Користувачеві get_some_name()насправді не потрібен коментар. Що він робить і що повертає, очевидно з коду. Що немає сеттера - це потрібно зробити, тому що його там немає.

У версії B я задокументував те, що потрібно коментувати. У геттера немає коментаря доксигену, але в ньому є коментар, в якому йдеться про відсутність сеттера.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.