DxLibEx 命名規則、記述スタイルの議論

Wiki https://github.com/Nagarei/DxLibEx/wiki/Coding_Style

これに書く内容を議論する #1 より

Nov 14 '15 12:11 yumetodo

とりあえず、各識別子の命名法で問題になりそうな物を列挙

関数
メンバ変数
define
- 案：DXLIBEX_から始まり大文字と_のみからなる
定数
- 案：defineと同じ
enum
enum class
class
struct

その他

const&
- 案：const T& v
グローバル名前空間上に出す識別子等
- 案：defineとnamespace dxleのみ

Nov 14 '15 22:11 Nagarei

const&

const T& vでいいと思います

グローバル名前空間上に出す識別子等

defineとnamespace dxleのみで不都合が出るとは思えないのでそれでいいかと。

define DXLIBEX_から始まり大文字と_のみからなる

namespaceと揃えてDXLE_のほうがいいと思います。

定数

enum/enum class以外の定数と言うとstatic constかconstexprのことでしょうか？それだとその命名規則は冗長では・・・(namespace書くのに更にDXLIBEX_と書くのか)

・・・そういえばconstexprどうしましょう。constexpr関数やconstexpr delegating constructorに関してはVSの対応が不十分なので使えませんが、

#if defined(_MSC_VER)
#if _MSC_VER < 1900
#define DXLIBEX_CONSTEXPR_OR_STATIC_CONST static const
#else
#define DXLIBEX_CONSTEXPR_OR_STATIC_CONST constexpr
#endif
#endif

とかして、定数として使ってもいいと思います

メンバ変数

privateメンバーは末尾に_(アンダースコア)をつけるとか、m_から始めるとかですか？

関数

DrawOnかdraw_onかみたいな話ですかね？

struct

template特殊化のためのstruct使用の話でしょうか・・・？

Nov 15 '15 02:11 yumetodo

そういえば

const T *
T const*

の話もありますね・・・。使うかわからないけどT const * const * constとか

Nov 15 '15 03:11 yumetodo

define

ではDXLE_にしましょう。

定数 static constかconstexprのことでしょうか？

そうです。確かに助長かもしれませんね..。では「大文字と_のみ」というのでどうでしょうか？

constexpr

DXLIBEX_CONSTEXPR_OR_STATIC_CONSTだと書きづらいのでDXLE_STATIC_CONSTEXPRはどうでしょう。

メンバ変数関数

そういう事です。

struct

classとstructで名前に差をつけたほうが良いかという事です。classの末尾に_cを付けるとすると変えたほうが良いかもしれないと思ったので。

Nov 15 '15 03:11 Nagarei

DXLE_STATIC_CONSTEXPR

ですね。

https://github.com/bolero-MURAKAMI/Sprout/blob/master/sprout/config/suffix.hpp この辺も参考にしようと思うんですが、そろそろ#defineまわりはコンパイラーごとにconfig作ってそれにしたがってそれぞれ実装したほうがいい気がしてきました・・・。

classの末尾に_cを付けるとすると変えたほうが良いかもしれないと思ったので。

あ、point_cのことでしょうか。pointだといくらnamespaceでくるむと言っても、using namespaceしてる人にconflictが起こりそうで、じゃあ_cつけるか、くらいの感じでつけたので・・・。

Nov 15 '15 04:11 yumetodo

https://github.com/Nagarei/DxLibEx/wiki/Coding_Style

更新しました

Nov 15 '15 04:11 yumetodo

ポインタのことを忘れていました...。 const T&に合わせてconst T*でどうでしょう？

コンパイラーごとにconfig作って

それが良いと思います。やるならconfigフォルダを作ってその中に入れましょう。ついでにDxLibEx_LINKもそこ入れて一緒に編集する形にしましょう。

Nov 15 '15 05:11 Nagarei

T const * const * constとかの場合はまあ考えなくていいか。 https://github.com/Nagarei/DxLibEx/wiki/Coding_Style 更新しました。

Nov 15 '15 06:11 yumetodo

こっちかな？ defineをDXLE_に修正しておきました。ちなみにこの命名規則はインクルードガードにも言えるので注意してください。

あとdefine名に数字を入れる事を許可してもよいでしょうか？

Nov 15 '15 12:11 Nagarei

ちなみにこの命名規則はインクルードガードにも言えるので注意してください。

そういえばそれについて決めていなかった。私が作ったやつだとINC_xxxx_HPPみたいな感じになってるんですが。

インクルードガードなので長いほうがいいんですが、日付を入れるのはどうなんだろうという気がします。

#ifndef INC_DXLE_(ファイル名大文字)_H(PP)_
//以下略

というのを提案します

あとdefine名に数字を入れる事を許可してもよいでしょうか？

defineに限らず定数にも許可していいと思います。

Nov 15 '15 14:11 yumetodo

三項演算子はどうしましょう？つまり

#include <string>
#include <utility>
#include <numeric>
#include <stdexcept>
#include <cctype>
int calc_check_digit(const std::string& n) noexcept(false) {
    if (11 != n.size()) throw std::runtime_error("n.digit must be 11");
    const int r = std::accumulate(n.rbegin(), n.rend(), std::pair<int, int>{}, [](const auto& s, const char& e) -> std::pair<int, int>{
        if(!std::isdigit(e)) throw std::runtime_error("n.digit must be 11");
        return {s.first + (e - '0') * ((5 < s.second) ? s.second - 4 : s.second + 2), s.second + 1};
    }).first % 11;
    return (0 == r || 1 == r) ? 0 : 11 - r;
}

三項演算子の条件文を()でくくるか、という話です。

Nov 15 '15 17:11 yumetodo

インクルードガード

予約語を増やしたくないのでDXLE_INC_でどうでしょう。日付を入れているのは万一同じ名前のファイルがあった場合に備えるためです。日付以外の方法として、例えばconfigフォルダの中にあるLINK.hではDXLE_INC_CONFIG_LINK_H_みたいにディレクトリ構造をインクルードガードに入れるのはどうでしょうか？

defineに限らず定数にも許可していいと思います。

確かにそうですね。

三項演算子

個人的にはくくったほうが良いと思いますが、特にこだわりはないです。

Nov 16 '15 10:11 Nagarei

というかルートフォルダーに無いものはルートから見たフォルダー名を入れてしまいましょう。 ./config/config.hppだったら

#ifndef DXLE_INC_CONFIG_CONFIG_HPP_
//以下略

Nov 16 '15 11:11 yumetodo

それで行きましょう。

Nov 16 '15 11:11 Nagarei

参考になりそうなのでとりあえず張るだけ張っておく。 Google C++スタイルガイド

まだ決まってない部分（型名、変数名、定数名、関数名）も決めねば...。

Dec 11 '15 12:12 Nagarei

別のProjectで似た話になっているので貼っておきます https://github.com/yumetodo/2015_C_Textbook/issues/59

命名はなるべくC++のSTLとDxLibに合わせたい・・・。ただ私は関数名に大文字が出るのが嫌なんですよね、個人的に。

void DoSomething();
void do_something();//私はこっち

Dec 11 '15 12:12 yumetodo

関数名

普段は小文字+_で、DxLibの関数に似たものがある場合は大文字区切りを使うというのはどうでしょう？

//screenクラスのメンバ関数
void drawn_on(...);
int SetDrawScreen()const;//DxLibのSetDrawScreenに似ている

Dec 12 '15 07:12 Nagarei

括弧の省略

絶対しないです。if,for,while全てにおいて、必ず書いてます。（一行に詰めるときでも）Ｗｉkiに追加して良いですか？

if,for,while,関数定義時の括弧の位置

この三つの内ならどれでも良いのではないでしょうか。この三つならわかりづらくなることは少ないと思うので。僕はなんとなく条件や処理が長いと思ったら一番下で、それ以外のときは上二つのどちらかにしてます。

    if (...){
        ...
    }
    if (...) {
        ...
    }
    if (...)
    {
        ...
    }

Dec 12 '15 10:12 Nagarei

関数名

いや、揃えたほうがいいと思うんですよね・・・。いっそ全部大文字区切り禁止します？その逆はsize()関数をSize()と書くのはMFCみたいで嫌いです。(関数名エイリアスがほしい)

括弧の省略

一行に詰めるときは省略しますね・・・。

char* p;
while(getchar() != '\n');
if(nullptr == p) std::quick_exit();

if,for,while,関数定義時の括弧の位置

if (...) {
     ...
}

しか書かないですね・・・。そもそもそんなに長いif文は条件をひっくり返すか関数化して短くしますし。

Dec 12 '15 12:12 yumetodo

関数名

DxLibの関数をラップするのに今は正規表現を使っているので、変換が面倒という理由もあってですね...。パーサーを作れば良いだけの話なんですが...。

　括弧の省略

慣れれば気にならないですよ。一行のままさらに詰め込むという事態もたまに起こりますし、括弧はつけたほうが良いと思います。（そもそも一行にif含めて3文はやりすぎですが...。）

char* p;
while(getchar() != '\n'){}
if(nullptr == p){ std::cerr << "error\n"; std::quick_exit(); }

if,for,while,関数定義時の括弧の位置

では

if (...) {
     ...
}

で行きましょう

関数のときの括弧の位置

関数のときの括弧の位置はどうしましょうか。僕は普通の関数のときは

void f()
{
}

ですが、inline関数の時は一行に詰め込んだり、

inline void f() {
}

になったりします。

Dec 12 '15 13:12 Nagarei

関数のときの括弧の位置

https://github.com/yumetodo/2015_C_Textbook/issues/59 でも同じ話があったんですが、

struct game_c::Impl {
    Impl(const dxle::pointi& bouninngennA_p, const dxle::pointi& bouninngennB_p)
        : m_window_s(static_cast<int>(WINDOW_WIDTH), static_cast<int>(WINDOW_HEIGHT)), m_state(), m_back_img(dxle::Graph2D::MakeScreen(m_window_s.x, m_window_s.y)),
        m_img(make_image_array()), m_sound(make_sound_array()), score(),
        m_bouninngenn{ {
            { bouninngennA_p, &m_img["bouninngennA"], &m_img["bouninngennA_fall"]},//棒人形A
            { bouninngennB_p, &m_img["bouninngennB"], &m_img["bouninngennB_fall"]} //棒人形B
        } }
    {
        this->m_back_img.DrawnOn([this]() {m_img["gake"].DrawExtendGraph({}, m_window_s, false); });
    }
    void state_init() NOEXCEPT;
    bool normal_con_f() const NOEXCEPT;
    void move_x(int limit_l_x, int limit_r_x) NOEXCEPT;
    void fadeout_prelude_masseage();
    void fall_bouninngenn(size_t bouninngenn_no, const std::deque<dxle::pointi>& pos_record);
    const dxle::pointi m_window_s;
    keystate m_state;
    dxle::Graph2D::Screen m_back_img;
    img_arr_t m_img;
    sound_arr_t m_sound;
    uint8_t score;//0-100
    std::array<obj_info, 2>m_bouninngenn;
};

のように{のまえにいろいろ書くときに、一貫性がないので

void f()
{
  //do something
}
void g(){}

で行きましょう

関数名

http://qiita.com/arai-wa/items/ceb28523c14177148ce4

一行のままさらに詰め込むという事態

やめましょうw

Dec 12 '15 13:12 yumetodo

正規表現での大文字小文字の変換

visual studioのIDEで\uをやる方法がわからない...。

Dec 12 '15 22:12 Nagarei

VSではやり方わからないですね・・・。Sublime Textでは成功していたので・・・。

Dec 12 '15 23:12 yumetodo

wikiに括弧について記述を追加しました。

Dec 14 '15 11:12 Nagarei

メンバ関数の宣言と定義の位置について

宣言と一緒に定義を記述
.hと.hppに分けて記述

とありますが、使い分けをどうしましょう？短い関数は宣言と定義を一緒に書くとして、「短い関数」の定義はどうしましょう？

Dec 24 '15 09:12 Nagarei

#20 よりクラスの命名規則を決める

Dec 24 '15 12:12 Nagarei

クラスの命名規則

区切り
- 大文字区切り
- _区切り
文字
- 小文字
- 大文字

文字は小文字の方が良いと思いますが、区切りをどうしましょう？

Dec 24 '15 12:12 Nagarei

私一人なら、_区切りで小文字にするんですが・・・。

Dec 24 '15 14:12 yumetodo

@Nagarei そういえば https://github.com/Nagarei/DxLibEx/commit/63de26fde6cf6a97a9228158514caf288f9de178 でも修正したんですが、return文にstd::moveを書かないことを明文化しましょう。 VCは何も言ってきませんが、Clangは警告出しますので。

Dec 31 '15 15:12 yumetodo

return文にstd::moveを書かない

右辺値参照を戻り値とする関数以外ではそういう事にしましょう。 wikiのCoding_Styleに書いときます。

Jan 02 '16 07:01 Nagarei

DxLibEx DxLibEx copied to clipboard

命名規則、記述スタイルの議論

DxLibEx
DxLibEx copied to clipboard