yumetodo commented 9 years ago

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

これに書く内容を議論する

1 より

Nagarei commented 9 years ago

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

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

その他

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

yumetodo commented 9 years ago

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使用の話でしょうか・・・？

yumetodo commented 9 years ago

そういえば

const T *
T const*

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

Nagarei commented 9 years ago

define

ではDXLE_にしましょう。

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

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

constexpr

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

メンバ変数関数

そういう事です。

struct

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

yumetodo commented 9 years ago

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つけるか、くらいの感じでつけたので・・・。

yumetodo commented 9 years ago

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

更新しました

Nagarei commented 9 years ago

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

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

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

yumetodo commented 9 years ago

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

Nagarei commented 9 years ago

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

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

yumetodo commented 9 years ago

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

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

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

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

というのを提案します

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

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

yumetodo commented 9 years ago

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

#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;
}

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

Nagarei commented 9 years ago

インクルードガード

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

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

確かにそうですね。

三項演算子

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

yumetodo commented 9 years ago

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

#ifndef DXLE_INC_CONFIG_CONFIG_HPP_
//以下略

Nagarei commented 9 years ago

それで行きましょう。

Nagarei commented 8 years ago

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

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

yumetodo commented 8 years ago

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

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

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

Nagarei commented 8 years ago

関数名

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

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

Nagarei commented 8 years ago

括弧の省略

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

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

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

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

yumetodo commented 8 years ago

関数名

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

括弧の省略

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

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

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

if (...) {
     ...
}

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

Nagarei commented 8 years ago

関数名

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() {
}

になったりします。

yumetodo commented 8 years ago

関数のときの括弧の位置

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

Nagarei commented 8 years ago

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

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

yumetodo commented 8 years ago

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

Nagarei commented 8 years ago

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

Nagarei commented 8 years ago

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

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

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

Nagarei commented 8 years ago

20 より

クラスの命名規則を決める

Nagarei commented 8 years ago

クラスの命名規則

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

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

yumetodo commented 8 years ago

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

yumetodo commented 8 years ago

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

Nagarei commented 8 years ago

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

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

Nagarei commented 8 years ago

クラスの命名規則

_区切りで小文字にしましょう。

Nagarei commented 8 years ago

@yumetodo ファイルの命名規則はどうしましょう。 .hppを原則にするという事ですが、

.hを使うのはどんなときか
宣言ファイルと定義ファイルを分ける場合.hと.hppなのか.hppと_impl.hppのようにするのかを決めておきたいです。

yumetodo commented 8 years ago

個人的には実装とそうでないものは名前ではなくフォルダ階層で分けたほうがいいのかなと思っています。 array.hppの実装は./array/array.hppみたいに .hはC言語として扱えるものだけにするべきかなと思っています。

Nagarei commented 8 years ago

texture_bridgeのtexture/texture2d.hとtexture/texture2d.hppみたいなのはどうすれば良いでしょう？

yumetodo commented 8 years ago

texture/texture2d.hとtexture/texture2d.hpp

texture/texture2d.hppとtexture/texture2d/texture2d.hpp

とかですかね、先のルールでいくと

Nagarei commented 8 years ago

分かりました。それで行きましょう。あと、ファイル名自体はsnake_caseで良いですかね？

yumetodo commented 8 years ago

はい

Nagarei commented 8 years ago

77 より文字数の一行当たりの文字数の制限に関して

@soukouki 自分は後者に賛成ですかね。(140か・・・、100くらいでやりたいな)

@yumetodo templateやると、100だと全然足りないというか、そんな狭いモニターでコーディングするないというか、140とは言わんから120は許してほしいというか。

@Nagarei 文字数は、通常のクラスのファイルとTMP系及び実装のファイルで制限を分けるべきかと思います。TMPはどうしてもインデントが多くなるので。

soukouki commented 8 years ago

あんまり長いと目で追うのが大変というか、インデントの部分を含まない長さがあまり長いのはちょっと。

yumetodo commented 8 years ago

インデント含めて140(tabを4文字とカウント)文字と思っていたのですが。 templateの型制約の部分とかは目に入らなくてもコード読むのにさほど支障が無いので画面からはみ出してもいいかなと思っていたりします。 #77 がマージされてからいう話ではないですが。

    template<typename T, enable_if_t<std::is_nothrow_move_constructible<T>::value && std::is_nothrow_move_assignable<T>::value, nullptr_t> = nullptr>

これは147文字ありますが一行で書きたい。画面端で折り返しとかしなければ支障は無いかなと

Nagarei commented 8 years ago

誰にとって見やすいのかというのが難しいですね...。 yumetodoさんの例のような場合はほとんどの人がそこに興味がない訳なので、見やすくするために改行をするより、読み飛ばせるように一行にまとめたほうが良いのかなと僕は思います。

Nagarei / DxLibEx

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

1 より

20 より

77 より文字数の一行当たりの文字数の制限に関して