社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

共同開発環境におけるコーディングスタイルの変更に関する調査
小倉 直徒†

柗本 真佑†

秀明††

畑楠本 真二†† 大阪大学大学院 情報科学研究科 〒 565–0871 大阪府吹田市山田丘 1–5†† 奈良先端科学技術大学院大学 情報科学研究科 〒 630–0192 奈良県生駒市高山町 8916–5
E-mail: †{n-ogura,shinsuke,kusumoto}@ist.osaka-u.ac.jp, ††hata@is.naist.jp
あらましソースコード内における，インデントの種類や演算子前後のスペースの有無，変数名の命名規則といった記法に関するルールを，コーディングスタイル（以下スタイル）と呼ぶ．スタイルはプログラムの本質に影響を与えないことから，正解/不正解のはっきりした問題ではなく，開発者ごとのプログラミング経験や文化が反映された一種の「好み」の問題であるといえる．しかしながら，複数の開発者が参加する共同開発環境では，その一貫性や統一作業が重要となる．本研究では，スタイル統一が容易な開発環境実現の予備調査として，共同開発環境におけるスタイルの実情を調査する．調査では 4 種類の OSS を対象として，ソフトウェア内でのスタイルの一致度を算出し，この値に基づいて 4 つの調査項目について議論する．
キーワード

Java，コーディングスタイル，リポジトリマイニング，スタイルの不一致度

1. ま え が き妨げに繋がるとも考えられる．一般的に，スタイルはコーディング規約等で規定されるが，全ての開発者にそのルールを遵守

ソースコード内における，インデントの種類（スペース/タさせることは容易ではない．また，スタイルの種類が多岐に渡ブ）や演算子前後のスペースの有無，変数名の命名規則といっることから，全種類のスタイルについて規定することも現実的た記法に関するルールを，コーディングスタイル（以下スタイではない．近年では，IDE やフォーマッタ（注 1） 等のツールの登ル）と呼ぶ．このスタイルは，プログラムの持つ本質的な振る場しており，ローカル環境内で一貫したスタイルを適用するこ舞いには一切影響を及ぼすことはないものの，開発者に対するとは容易になった．しかし，ツールごとのスタイル規定値が異コードの視認性や可読性に強い影響を与える [1]. スタイルの種なるため，複数開発者の間での一貫性の確保はやはり容易では類は多様であり，統合開発環境 Eclipse では 300 種類以上のスない．

タイル設定項目が用意されている．

本研究では，スタイルの統一が容易な開発環境実現の予備調

スタイルはプログラムの本質に影響を与えないことから，正査として，共同開発環境におけるスタイルの実情を調査する．

解/不正解のはっきりした問題ではなく，開発者ごとのプログラ調査では 4 種類の OSS を対象として，ソフトウェア内でのスミング経験や文化が反映された一種の「好み」の問題であるとタイルの不一致度を算出し，この値に基づいて 4 つの調査項目いえる．例えば，分岐命令（if や for）直後のスペースを挿入すについて議論する．本研究の貢献は以下のとおりである．

るか/否かや，ブロックの開始を表す括弧 { を分岐命令と同じ•行に書くか/次の行に書くかは，好みの分かれやすいスタイルでした．

ある．また，スタイルはプログラミング環境の進化に伴って変•化しているといえる．横幅 80 文字で強制折り返しというスタイルは，パンチカードの物理的な横幅制限から引き継いだものであるが，近年のディスプレイ解像度の増加に伴ってその値は大きくなりつつある．実際に Google による Java のコーディ
ング規約 [2] では，一行の最大文字数は 100 と指定されている．

ソースコードからスタイル特徴を抽出する手法を提案
ソフトウェアの開発過程においてスタイルの違反と修正が繰り返し行われていることを明らかにした．

•

違反の多いスタイルの種類を特定した．

2. ス タ イ ル
2. 1 スタイルの定義

このようにスタイルは正解のない好みの問題ではあるものの，本研究では，コンパイル後の生成物に影響を及ぼさない，ソー複数の開発者が参加する共同開発環境ではその一貫性や統一作

スコード内の表現のことを，スタイルと定義する．スタイルに業が重要となる．スタイルの不一致はコードの可読性の低下をは，トークン間の空白の有無，識別子名の命名や順序，あるい招くだけでなく，改行の位置が好みと異なる/スペースを挿入したくなるといった，本質的なプログラミング作業時の思考の（注 1）：http://checkstyle.sourceforge.net/—1—

はプログラム構文などが含まれる．大別して以下に分類した．

で表される．Eclipse の空白に関する設定項目は 161 個あるたa ) トークン同士の区切り要素

め，i は 1 <=i<
= 161 である．ただし後述するようにスタイル•

スペース: 括弧の前後にスペースを挿入するか等の抽出において，スタイルの項目を新規に定義するため，実際•インデント: クラスのボディでインデントするか，インは 161 個よりも多くなる．SI 度は 0 から 0.5 までの値をとり，デントのスペースの数等•

改行: if のあとに改行を挿入するか等値が大きいほどスタイルは不統一であることを示す．例えばある特徴名において，特徴値が空白ありである特徴の数が 10 で，b ) 識別子の命名規則と宣言順序空白なしである特徴の数が 2 のとき，その特徴名 i の SIi 度は•2/12 = 0.16 となる．空白ありとなしそれぞれの出現数が同数

命名規則: キャメルケースかスネークケースか，ハンガリアンを用いるか等•

宣言順序: メソッド宣言が先か変数宣言が先か等

2. 2 本研究で対象とするスタイル
スタイルの設定項目はエディタやフォーマッタなどのツールによって異なる．それらで設定可能な項目を全て調査し対象とするのは現実的ではない．そのため本研究では，Eclipseであるとき，SIi 度は 0.5 となり，その値は SI 度の上限である．

3. スタイル特徴の抽出手法
3. 1 スタイル特徴
スタイル特徴とは，スタイル設定によってソースコードが変化するときの，以下の要素の組み合わせである．

で設定可能な空白の挿入に関するもののみを対象とする．対•

ソースコード上の位置

象となる設定項目は 161 個存在する．空白の挿入に関する設•

スタイル特徴名

定で指定可能な値は insert または do_not_insert の 2 値の•スタイル特徴値

みである．insert はトークン間に空白を挿入することを示

スタイル特徴名は Eclipse のスタイルで定義された設定可能なし，do_not_insert は空白を挿入しないことを示す．以降は値の名前である．スタイル特徴値は空白ありまたは空白なしのinsert を空白あり，do_not_insert を空白なしと表す．

2 値である．スタイル特徴値が空白ありの場合は，位置の示す対象とする項目の一部を表 1 に示す．“空白なしの例”は空白なしの設定でフォーマットした場合，“空白ありの例”とは空白ありの設定でフォーマットした場合の，Java ソースコードの一部を示している．

トークンの前または後に空白が存在することを示し，空白なしの場合は空白が存在しないことを示す．

3. 2 手法の概要
本手法の概要を図 1 に示す．本手法の入力は，Java のソー

2. 3 関 連 研 究スコードである．出力は入力ソースコードから抽出したスタイ

スタイルの研究は長年に渡って多数行われている．特に抽象ル特徴の集合である．

構文木を用いてソースコードをフォーマットする手法が数多く

3. 3 Step1: 字句解析・構文解析

提案されている [3] [4] [5]．Spinellis らは長期間の開発における入力されたソースコードを，トークン単位の文字列に分割す

スタイル違反の変化について調査した．43 年間にわたる Unixる．また，構文解析により，分割したトークンが抽象構文におの開発において，後述されるスタイルの不一致度が年々減少しいてどの要素に属するかを判定する．ていることを明らかにした [6]．Buse らは開発者の感じるソー

3. 4 Step2: スタイル特徴名のマーキング

スコードの可読性はスタイルによって変化することを明らか抽出対象に該当する抽象構文のトークンを探し，そのトークにした．また全ての開発者にとって最適なスタイルは存在しン前後のトークン間に対して，スタイル特徴名をマーキングないことを報告した [7]．Bacchelli らは違反スタイルの発見がする．

コードレビューの重要な役割の 1 つであることを報告した [8]．

3. 5 Step3: スタイル特徴値の抽出すなわちスタイルの統一のために手間を要しているといえる．

スタイル特徴名をマーキングされたトークン間に空白が存在Caliskan らはソースコードから開発者を特定する手法を提案しするか判別し，空白の有無をスタイル特徴値として抽出する．

た [9]．この手法では，スタイルと抽象構文木の特徴は開発者ご抽出したスタイル特徴値を，トークンの位置とスタイル特徴名とに異なることを利用している．

を組み合わせてスタイル特徴として出力する．

2. 4 SI度

スタイルが統一していないことの指標として SI(Style In-

ただし以下に該当する場合，上記とは異なる処理を行う．それぞれの例として図 2 に示す．

consistency) 度 [6] を用いる．SI 度とは，あるスタイル設定a ) 同一の空白に複数の特徴名がマーキングされた場合の取りうる値が a または b で，i 番目のスタイル設定が適用さ

図 2a のように，複数のスタイル設定が同一の空白の有無に変れた箇所の出現数をそれぞれ ai および bi としたとき，i 番目の化を及ぼす場合がある．このとき，複数の特徴名が空白にマー

スタイルの SIi 度は，キングされる．複数のスタイル設定のうち，1 つでも特徴値がSIi =min(ai , bi )ai + biで表される．また，全てのスタイル項目における SIall 度は，∑nmin(ai , bi )i=1
SIall = ∑n

空白ありなら空白が挿入されるため，新たな特徴名 a|b を定義し，そのトークンからは新たな特徴名の特徴のみを抽出する．
ただし空白が存在しない場合，特徴名 a および b それぞれの値を，空白なしとして抽出する．

a + bii=1 i—2—

表 1: 空白のスタイル設定の例
スタイル名空白なしの例

空白ありの例（␣は該当箇所）

space before opening brace in type declarationc l a s s HelloWorld {c l a s s HelloWorld {space before opening paren in method declaration

void main ( S t r i n g [ ] a r g s ) void main ( S t r i n g [ ] a r g s )space after opening paren in method declaration

void main ( S t r i n g [ ] a r g s ) void main ( S t r i n g [ ] a r g s )space before opening bracket in array type reference

void main ( S t r i n g [ ] a r g s ) void main ( S t r i n gpublic class HelloWorld {public static void main(String[] args){
System.out.println("Hello, world.");}}

publicclass

Step1
字句解析・
構文解析

publicclass

HelloWorld[ ] args )・・・{

public{public ・・・

型定義

Step2
スタイル特徴名のマーキング
public
Step3
HelloWorld{ public ・・・ スタイル特徴の抽出
型定義
型定義の始め波括弧の前

class

HelloWorld

空白あり

トークン位置

スタイル特徴名

空白24［文字目］

型定義の始め波括弧の前あり

図 1: 手法の概要

if(if文!

true) ・・・

空白なし

単項式

if文の始め丸括弧の後単項式の単項演算子の前

空白あり

スタイル特徴名

空白

if文の始め丸括弧の後なし

単項式の単項演算子の前なし

return!

true

return文

単項式;

a=“b”
代入文

return文のreturnの後単項式の単項演算子の前+ ⏎;二項式二項式の二項演算子の後

スタイル特徴名

空白

スタイル特徴名

if文の始め丸括弧の後|単項式の単項演算子の前ありなしなし(b) 構文上必ず存在する空白に特徴(c) 行頭または行末のトークンの空白名がマーキングされた場合の場合(a) 同一の空白に複数の特徴名がマーキングされた場合

空白

“a¥n”

スタイル特徴名空白

図 2: スタイルの抽出に関する場合分けb ) 構文上必ず存在する空白に特徴名がマーキングされた
場合
図 2b のように，構文上必ず空白を挿入しなければならないことがある．例えば，return 文において return キーワードのを取得するツール cqmetrics（注 2） を公開しており，この中にはスタイル特徴を抽出する機能が存在する．このツールには以下の欠点が存在する．

•

構文解析を行わないため，抽出されるスタイル特徴の特後に単項演算子が続く場合は，トークンの区切りとして必ず空徴名は構文上の要素名を含まない．例えば，for 文と if 文の始白を挿入しなければならない．そのような場合，マーキングさめ丸括弧から同一のスタイル特徴名の特徴を抽出する．

れた空白からはスタイル特徴を抽出しない．

•3.5 節で挙げた場合分けの処理を行っていない．そのたc ) 行頭または行末のトークンの空白の場合

め，誤った特徴を抽出している場合がある．例えば，単項演算

図 2c のように，行内の最初のトークンの前や，最後のトーク子の前には空白を挿入しないという規約に従っている場合でンの後にトークン間からは，スタイル特徴を抽出しない．これも，図 2b と図 2a における単項演算子の前の空白の有無は異ならのトークン間には改行が含まれるが，改行は最大桁指定などるため，スタイルが不一致であると判定される．

空白とは異なる設定に基いて挿入されるためである．

3. 6 Spinellis らの手法との違い

2 つの欠点により，SIall 度が本手法よりも高く検出されている可能性がある．

Spinellis らは C 言語のソースコードから様々なメトリクス（注 2）：https://github.com/dspinellis/cqmetrics—3—4. 研究目的と調査項目
4. 1 研 究 目 的本研究の目的は，ソフトウェア開発においてスタイルの統一にかかる労力を明らかにすることである．研究目的を達成するため，以下の調査項目を設定した．

Java のソースコード行数も計測する．
5. 3. 2 調査項目 2 に対する実験の手順
本実験では，開発過程においてスタイル違反を含むコミットがどの程度行われたかを明らかにする．
実験ではまず対象ソフトウェアにそのソフトウェアで規定された正しいスタイル設定の集合を決める．この正しいスタイル

4. 2 調 査 項 目

設定の集合は，コーディング規約等のドキュメントから生成す

4. 2. 1 調査項目 1

ることも可能であるが，全てのスタイルについて詳細に決めら

Spinellis らは C 言語で実装された Unix におけるスタイルれているとは限らない．そのため，本実験では各リビジョンでの違反は漸減していると報告している [6]．この知見が Java ソ抽出された特徴のうち，過半数を占める特徴値を正しいスタイフトウェアに対しても当てはまるのかを確認するため，複数のルと定義する．このスタイル集合をもとに，Java のソースコー

Java ソフトウェアを対象に開発過程における SIall 度の変化をドに追加された行に違反スタイルが含まれているかを判定する．

調査する．

対象とするコミットは，1 つ以上の Java ソースコードが変4. 2. 2 調査項目 2
ソフトウェア開発において，スタイル違反がどの程度発生しているかを調査する．指標として，版管理上の全コミットのうち，スタイル違反を含むコミットの割合を算出する．

更されたコミットである．

5. 3. 3 調査項目 3 に対する実験の手順
本実験では実験 2 で検出されたスタイル違反のうち，後のコミットでスタイル修正されたものを対象とする．スタイル修正

4. 2. 3 調査項目 3のコミットとは，空白のみの変更が行われた行において，正しソフトウェア開発において，スタイル修正がどの程度発生しいスタイル設定の集合に違反したスタイル特徴が全て修正されているのかを調査する．調査項目 2 と同様に，指標としてスタたものを含むコミットのことである．すなわち，同一のスタイイル修正を含むコミットの割合を算出する．

ル特徴名を持つスタイル違反を全て修正した行が存在した場合，4. 2. 4 調査項目 4
どのようなスタイルの違反が多いのかを調査する．違反の多いスタイルをコーディング規約等のドキュメントにおいて強調することで，今後のスタイル違反が少なくなることが期待される．

スタイル修正が行われたとみなす．

5. 3. 4 調査項目 4 に対する実験の手順
最新リビジョンを対象に各特徴名 i の SIi 度を算出する．ただし出現数が 100 以上のスタイルのみを対象とする．

5. 4 結果と考察

5. 実

験

5. 1 準備

5. 4. 1 調査項目 1 に対する実験の結果と考察
各ソフトウェアのリビジョンごとの SIall 度と LOC の推移を図 3 に示す．開発過程の後半において，Guava と JUnit4 の3 章で述べた手法をもとにソースコードからスタイル特徴を

SIall 度は減少傾向にあるが，log4j と SpirngFramework では変抽出するツールを，Format Feature Extractor として実装した．

化に傾向はない．また LOC について，log4j 以外は増加の傾向

本ツールはウェブサイト上（注 3） で公開している．本ツールの制にあるが，log4j は増加の傾向にあるとはいえない．

限として，抽出可能なスタイル特徴は Eclipse で設定可能な空白に関するスタイル特徴のみである．

既存研究 [6] では 1973 年から 2015 年までの 37 年間という長期間に渡って SIall 度の変化を調査した．1995 年以前は SIall

5. 2 実 験 対 象

度とその変化は大きいが，1995 年以降の SIall 度は小さくその本実験は複数の開発者によって開発された 4 つの Java のソ変化も小さい．理由として，最近はエディタやフォーマッタ等フトウェアを対象に行った．対象ソフトウェアは git で版管理のツールの充実により，スタイルの統一が容易になったことがされており，リポジトリは GitHub から取得した．対象ソフト挙げられる．また，スタイルを統一させることの重要性が十分

ウェアの概要を表 2 に示す．“行数”は最新リビジョンでの Java広まったことが考えられる．

ソースコードの行数を表す．

本実験で対象としたソフトウェアは全て 1995 年以降に開発

5. 3 実 験 手 順が開始されており，Unix における SIall 度の変化が小さい時期

5. 3. 1 調査項目 1 に対する実験の手順である．そのため，本実験で得られた結果も，SI 度が明らかに

4 つのソフトウェアの開発過程における SIall 度の変化を調査する．master または trunk ブランチに属する全リビジョン

表 2: 対象ソフトウェアの概要を対象として，各リビジョンの全ソースコードからスタイル特徴を抽出し，SIall を算出する．また同時に，対象リビジョンのソフトウェア

開発期間 [年] リビジョン数

Guava

74,136

開発者数

行数

114 374,603

log4j

15

3,275

2159,780（注 3）：http://sdl.ist.osaka-u.ac.jp/˜n-ogura/

JUnit4

152,115

159

39,722

2016 format-feature-extractor

SF（注 3）

813,312207

18,134（注 3）：Spring Framework—4—20,000(a) Guava

2014年12月

2013年12月0.06

600,000

0.04

400,000

0.02

200,000(c) JUnit4

2016年7月

2016年1月

2015年7月

2015年1月

2014年7月

2014年1月

2013年7月

2013年1月

2012年7月

0

2012年1月

0

2008年7月

2015年12月

2014年12月

2013年12月

2012年12月

2011年12月

2010年12月

2009年12月

2008年12月

2007年12月

2006年12月

2005年12月

2004年12月

2003年12月

2002年12月

2001年12月

0.000

800,000

2011年7月

0.005

1,000,000

2011年1月

0.010

0.1
0.08

2010年7月

0.015

1,200,000

2010年1月

0.020

(LOC)

LOC

(SI)
0.12

2009年7月

0.025

SI all(LOC)
45,00040,00035,00030,00025,00020,00015,00010,0005,000
02009年1月

LOC

0.030

2000年12月

2012年12月(b) log4j

SI all(SI)

2011年12月

0

2010年12月

2016年9月

2016年3月

2015年9月

2015年3月

2014年9月

2014年3月

2013年9月

2013年3月

2012年9月

2012年3月

2011年9月

2011年3月

2010年9月

2010年3月

2009年9月

0.000040,0002009年12月

0.000160,0002008年12月

0.000280,0002007年12月

0.0003(LOC)
100,000

2006年12月

0.0004LOC

120,000

2005年12月

0.0005

0.045
0.040
0.035
0.030
0.025
0.020
0.015
0.010
0.005
0.000

2004年12月

0.0006500,000
450,000
400,000
350,000
300,000
250,000
200,000
150,000
100,000
50,0000

2003年12月

0.0007(SI)

2002年12月0.0008

SIall(LOC)

2001年12月

LOC

2000年12月

SI all(SI)(d) Spring Framework

図 3: 各ソフトウェアにおける SIall 度と LOC の変化減少しているとはいえない結果となった．

修正しようとする実情が明らかになった．Guava はスタイル修JUnit4 では 2012 年 11 月に SIall 度が非常に小さくなっている．この期間において新しいコーディング規約を導入してお正を含むコミット数が小さく，スタイル違反がソフトウェア開発に与える影響は小さい．

り，全ての Java ファイルに対してフォーマッタを適用したた

5. 4. 4 調査項目 4 に対する実験の結果と考察

め，SIall 度が小さくなったと思われる．

最新リビジョンにおいて最も SIall 度の大きかった log4j を対

5. 4. 2 調査項目 2 に対する実験の結果と考察

象に実験を行った．表 5 に違反されやすいスタイルの一覧を示

実験の結果を表 3 に示す．“スタイル違反を含むコミット数”

す．この表では，ソースコード全体の中で 100 回以上出現してとは，“対象コミット”のうちそのコミットで追加された行にスいるスタイルのうち，SIi 度が高い上位 10 件のスタイルのみがタイル違反のスタイル特徴を含んでいる数である．log4j では示されている．

対象コミットのうち半分がスタイル違反を含んでおり，ソフトほとんどのスタイルが SIi 度 0.1 以上（すなわち，10 件中 1ウェアの保守に大きな影響を及ぼしている可能性がある．一方，件が違反）であり，これらのスタイルは開発者ごとの好みが分

SIall 度が開発過程において一貫して小さかった Guava は，スかれやすいスタイルであるといえる．特に 2 番目の if 直後の空タイル違反を含むコミットも少ない．

白は出現数が 1 万以上でありながら，SIi 度が 0.48 と極めて高

5. 4. 3 調査項目 3 に対する実験の結果と考察

く，log4j の中ではほぼ一貫性がないスタイルだと考えられる．

本実験の結果を表 4 に示す．“スタイル修正を含むコミット

また，違反されやすい構文要素の種類も確認できる．具体的数”とは，“対象コミット”のうちそのコミットでスタイル修正には，配列初期化に関するスタイル（#1，#3，#7，#10）や，のみが行われた行を含んでいる数である．log4j ではスタイル二項演算子に関するスタイル（#6，#8）などである．特に二修正が多数行われており，スタイル違反を放置するのではなく項演算子に関するスタイルは，前述の if 直後の空白と同様に出

表 3: スタイル違反を含むのコミット数

表 4: スタイル修正のコミット数

ソフトウェア 対象コミット数

スタイル違反を含む
コミット数
割合 [%]

Guava

3,510

166

4.7

ソフトウェア

対象コミット数

スタイル修正を含む
コミット数
割合 [%]

Guava

3,510

110.3

log4j

2,198

1,123

51.1

log4j

2,198

199

9.1

JUnit4

1,321

306

23.1

JUnit4

1,321

51

3.9

SF

10,210

1,688

16.5

SF

10,210162

1.6—5—表 5: log4j における違反の多いスタイル（出現数が 100 以上の上位 10 件のみ）
# スタイル名 (i)SIi 度

出現数最頻値132-

空白ありの例（␣は該当箇所）

int [ ] { 1 , 2 , 3 }1 space before closing brace in array initializer

0.50

2 space before opening paren in if

0.48 11,687 空白あり

3 space after opening brace in array initializer

0.46

114 空白なし

4 space before opening paren in for

0.36

233 空白なし

f o r ( i =0; i <10; i ++){

5 space before opening paren in catch

0.33

360 空白なし} catch ( E x c e p t i o n e ) {6 space after binary operator

0.223,207 空白あり

i f ( i >0)
int [ ] { 1 ,2 ,3}i=i+ 1
int [ ] {1 ,2 ,3}

7 space before opening brace in array initializer

0.22

179 空白あり

8 space before binary operator

0.21

3,470 空白あり

9 space after closing paren in cast

0.17

373 空白あり( short ) 10

10 space after comma in array initializer

0.08

324 空白あり

i n t [ ] { 1 , 2 , 3}

現数と SIi 度が高い．

i=i +1

今後の課題として，空白以外のスタイル特徴を抽出可能とす

これら違反されやすいスタイルについては，コーディング規ることや，本実験をより多くのソフトウェアへ適用し一般性を約等で開発上のルールとして明記するか，何かしらのツールに向上すること，スタイルの違反や修正は開発者ごとに特徴があ

よって一貫性を保つべきであると考える．別の解釈としては，るのかに関する調査が挙げられる．版管理上でスタイルの統一

log4j の中ではスタイルの一貫性にあまり関心がなく，スタイを支援する開発環境の実現も課題である．

ルの不一致が放置されやすいといった可能性もある．しかしな

謝辞 本研究は，日本学術振興会科学研究費補助金基盤研究

がら，1 節でも述べたとおりスタイルの不一致は可読性や視認（S）(課題番号：JP25220003)，および文部科学省研究費補助性の低下のみならず，プログラミング作業時の思考の妨げにつ金若手研究（B）（課題番号：JP26730155）の助成を得て行わながると考えられる．また，OSS においては他の開発者の参入れた．の妨げになるとも考えられる．スタイルの一貫性をどのようなツールでどのように確保するかに関しては，今後の検討課題である．

6. 妥当性への脅威
4 つのソフトウェアを対象に実験を行った．異なるソフトウェアを対象に実験を行えれば，得られる結果も異なる．
また，本実験のためにスタイル特徴を抽出するツールを開発した．本ツールに不具合が含まれていて正しい実験が行えていない可能性がある．本ツールはソースコードとともにウェブサイト上で公開しており，本実験は再現可能である．
また，本ツールで抽出可能なスタイルは，Eclipse で設定可能なトークン前後の空白に関するスタイルのみである．インデン
ト幅や改行などのスタイル設定は抽出できず，そのようなソースコードの変化も検出できない．したがって本実験で得られた
スタイル違反や修正のコミット数は，他のスタイルを検出対象に加えた場合よりも小さい．

7. あ と が き
本研究では，スタイル統一が容易な開発環境実現の予備調査として，共同開発環境におけるスタイルの実情を調査した．
結果，SIall 度の推移はソフトウェアによって異なり，推移に文献[1] P.W. Oman and C.R. Cook, “A taxonomy for programmingstyle,” Proceedings of the 1990 ACM Annual Conference onCooperation, pp.244–250, CSC ’90, ACM, New York, NY,USA, 1990. http://doi.acm.org/10.1145/100348.100385[2] https://google.github.io/styleguide/javaguide.html[3] R.D. Cameron, “An abstract pretty printer,” IEEE Softw.,
vol.5, no.6, pp.61–67, Nov. 1988.
[4] D.C. Oppen, “Prettyprinting,” ACM Trans. Program.
Lang. Syst., vol.2, no.4, pp.465–483, Oct. 1980.
[5] L.F. Rubin, “Syntax-directed pretty printing-a first step towards a syntax-directed editor,” IEEE Transactions on Software Engineering, vol.9, no.undefined, pp.119–127, 1983.
[6] D. Spinellis, P. Louridas, and M. Kechagia, “The evolutionof c programming practices: A study of the unix operating
system 1973–2015,” Proceedings of the 38th International
Conference on Software Engineering, pp.748–759, ICSE ’16,ACM, New York, NY, USA, 2016.
[7] R.P.L. Buse and W.R. Weimer, “Learning a metric for codereadability,” IEEE Trans. Softw. Eng., vol.36, no.4, pp.546–558, July 2010.
[8] A. Bacchelli and C. Bird, “Expectations, outcomes, andchallenges of modern code review,” Proceedings of the 2013
International Conference on Software Engineering, pp.712–721, ICSE ’13, IEEE Press, Piscataway, NJ, USA, 2013.
[9] A. Caliskan-Islam, R. Harang, A. Liu, A. Narayanan, C.
Voss, F. Yamaguchi, and R. Greenstadt, “De-anonymizingprogrammers via code stylometry,” Proceedings of the 24th
USENIX Conference on Security Symposium, pp.255–270,
SEC’15, USENIX Association, Berkeley, CA, USA, 2015.

一般性はなかった．また，全てのソフトウェアにおいてスタイルの違反と修正が行われており，開発者は本質的な振る舞い以外の変更に労力が割かれていることが分かった．違反されやすいスタイルは配列初期化や二項演算子に関するスタイルであった．共同開発においては，スタイルの統一を支援する何らかの仕組みが必要であるといえる．

—6—