# Outline for Online MTG3
- [第１回オンラインミーティング](https://hackmd.io/zIUjG3M2QsOjzwtQYcQx4w)
- [第２回オンラインミーティング](https://hackmd.io/rA8WAd7wSLG3Xnz8lLomNw)
## 前回まで
- コーディングスタイルに関する研究をする予定だった
- 現実的な題材を作るのが難しそう
- マイニングをしてみた結果javaのコーディングスタイルは実際にはあまり揺れがなく，脳波に影響がでるほど差があり，かつ一般性を持った題材を作ることが難しそう
## 今回のミーティングの目的
- 研究の方向性を決めたい
- 研究案の紹介
- 今後の日程調整
## 研究の前提
- プログラム理解 × 生体計測
- 実験は長くても90分
- 3時間以上拘束することはできない
- お借りできる生体計測デバイスは[NeXus](https://www.kicnet.co.jp/solutions/biosignal/biosignal-2/nexus/)と多人数で脳波を計測可能のemotive
- 実際題材に妥当性があること
- 脳波など生体メトリクスに変化が表れやすい題材であること
---
## 論文上でのコード理解
### 導入
- コード理解の研究はたくさんある
([Measuring Neural Efficiency of Program Comprehension - ESEC/FSE 2017](https://dl.acm.org/citation.cfm?id=3106268),
[Stuck and Frustrated or in Flow and Happy: Sensing Developers' Emotions and Progress - ICSE 2015](https://ieeexplore.ieee.org/document/7194617),
[Indentation: Simply a Matter of Style or Support for Program Comprehension? - ICPC 2019](https://conf.researchr.org/details/icpc-2019/icpc-2019-replications/1/Indentation-Simply-a-Matter-of-Style-or-Support-for-Program-Comprehension-))
- コードリーディングの機会はIDE上だけに限らない．
- 論文中にコードを載せる機会も沢山ある．= on PDF or 紙 or 本
- code reading on a paper (CRP)
- CRP固有の問題がある
- **シンタックスハイライト**：予約語のみハイライトされている場合が多く，IDE並みに構文情報に基づいたトークンの色分けがなされている訳ではない．また，そもそも予約語のハイライトすらないこともある．
- **画質**：画像としてスクリーンショットを貼り付けてあるだけであるため，コードの画質が荒いという問題もある
- **フォント**：コードの部分に等幅フォントが使用されていないなどの場合も存在している．
- 本研究では，論文中でのコード理解を調査する．
- 生体メトリクスの観点からCRPに伴って起こり得る影響を調べる．
### 実験手法
- ベースラインとして論文中のコードに多い，以下3つの条件を満たす簡単なコードを読解してもらう．
- 予約語のみハイライトされている (コメントもハイライトあり)
- フォントは等幅フォントを使用する
- ベクターフォントを使用する
---
**RQ1**: シンタックスハイライトがコード理解に影響を与えるか？
**RQ2**: フォントがコード理解に影響を与えるか？
**RQ3**: 画質がコード理解に影響を与えるか？
---
- 実験題材は1リードあたり約5分以内になるものを使用し，以下5つのコードを読んでもらう
ハイライト
|#|ハイライト|フォント|画質|
|--|---|---|---|
|1|予約語|等幅|ベクター|
|2|**IDE並み**|等幅|ベクター|
|3|**なし**|等幅|ベクター|
フォント
|#|ハイライト|フォント|画質|
|--|---|---|---|---|
|1|予約語|等幅|ベクター|
|4|予約語|**非等幅**|ベクター|
画質
|#|ハイライト|フォント|画質|
|---|---|---|---|
|1|予約語|等幅|ベクター|
|5|予約語|等幅|**低画質**|
- これ (5 reading) を1セットとし，3回繰り返す
- 1セット25分，一人当たり合計75分の実験
- 計測メトリクス
- 理解の時間
- 理解の精度
- 脳波から得られる感情（非等幅フォントや低画質のコードを読まされる不快感など）
- 視線による理解順序の違い([The impact of syntax colouring on program comprehension - PPIG 2015](https://pdfs.semanticscholar.org/d14b/edf3f58080ecf7a92f60746371b894a7bc08.pdf))
### 実験題材のサンプル
- ベースライン
- できるだけ簡単で，`if`,`for`がある，決まった出力値が得られるようなコードにした
- シンタックスハイライトは予約語がboldになり，コメントが薄い灰色，配列の要素が青になる程度
- 非等幅フォントのときにずれができるだけ大きく生じるように数字ではなくコード内で比較する対象は文字にした
- シンタックスハイライトがなくなった時に見づらくなるように，必要はないが，コメントを挿入した
- フルハイライト
- イメージとしてはintelliJやeclipseそのもののような感じ
- グレー
- 非等幅フォント
- フォントはArialを使用
- mやwを使えば結構ずれそう
- 低画質
- 読めないことはないが，不快には感じてもらえそう
- 実験題材
```java=
public static void main(String[] args){
//prepare two lists
List<Character> list1 = Arrays.asList('i', 'a', 'c', 'f');
List<Character> list2 = Arrays.asList('m', 'f', 'i', 'w');
for(int i = 0; i < list1.size(); i++){
for(int j = 0; j < list2.size(); j++){
// if arr1[i] equals arr2[j], print i and j
if(list1.get(i) == list2.get(j)){
System.out.println(i);
System.out.println(j);
}
}
}
}
```
### pros
- 現実的に起こり得る題材であるため，共感が得やすい
- 実験に結果がでると，「論文に載せるコードは○○にした方が読者に理解されやすい」などの結論を出すことができる
- 結果が出る可能性が高い．3つのファクタ x 計測メトリクスのいずれかで出れば少なくとも結果になる
### cons
- ~~フォントの差があまり大きくないため，感情的な差が生まれるかが微妙~~ wordで題材を作ることで解消
---
## コーディングスタイル
### 実験背景
- コーディングスタイルに関する問題はだれにでも起こる
- 実務でもスタイルを強要させられることがあるが，それにより潜在的に不快に感じているかもしれない．
### 実験手法1(今までの手法)
#### マイニングから変更するスタイルを変更する手法
- javaではあまり開発者による大きいスタイルの違いは少なそう
- 実際のjavaプロジェクトのスタイルの差のほとんどが空白関するものであり，カーニハンスタイルを実際に使用している人はほとんどいない
#### 変化させるスタイル
- キャストの`)`後の空白
- 配列初期化時の`{`後の空白
- 配列初期化時の`}`前の空白
<br>
- 実際にスタイルを変更してみた結果
```java=
public static void main(String[] args){
int[] arr = {3, 5, 2, 2, 3};
for(int i = 0; i < arr.length; i++){
if(arr[i] % 2 != 0){
System.out.println((float)arr[i] / (float)arr[(i + 1) % arr.length]);
}
}
}
```
```java=
public static void main(String[] args){
int[] arr = { 3, 5, 2, 2, 3 };
↑ ↑
for(int i = 0; i < arr.length; i++){
if(arr[i] % 2 != 0){
System.out.println((float) arr[i] / (float) arr[(i + 1) % arr.length]);
↑ ↑
}
}
}
```
- このような小さい違いでは脳波の差は生まれなさそう
### 実験手法2
#### 実験設計を変更する
- コードの種類を好き，嫌い，Javaプロジェクトの平均にする
- Javaプロジェクトの平均のコードは被験者の好きなスタイルに左右されることなく，マイニングの結果からすべてのスタイルの多数派となっているスタイルを選択したコードを作成する
#### いままでの手法案との違い
いままでの手法ではマイニングの結果から，スタイルの揺れが大きかったいくつかのスタイルを候補として，それを被験者のスタイルから変更しようとしていたが，この案では被験者のスタイルには関係なく，マイニング結果から各スタイルの多数派をJavaプロジェクトの平均的なスタイルと仮定する．
#### pros
- 各被験者の好きなスタイルとJavaの平均的なスタイルとの差を定量的に評価できることで，不快感を感じた人と不快感を感じなかった人でスタイルの差の面から考察のアプローチが出来る
- 例えば，好きなスタイルと平均のスタイルとの差が70%であった人には不快感を検出できたが，差が30%の被験者には不快感が検出されなかったなどが起こる可能性がある
#### cons
- 被験者によって好きなスタイルと平均のスタイルとの差が違うようになる．
- 被験者の量がかなり必要になる
- 実プロジェクトであまりスタイルに揺れがないということは，被験者達の間にもスタイルの差はほとんどない可能性がある
- 不快感を感じる境界は被験者によってバラバラである可能性がある
#### 実験題材のサンプル
- 自分の好きなスタイル
```java=
public static void main(String[] args){
int[] arr = {3, 5, 2, 2, 3};
for(int i = 0; i < arr.length; i++){
if(arr[i] % 2 != 0){
System.out.println((float)arr[i] / (float)arr[(i + 1) % arr.length]);
}
}
}
```
- Javaプロジェクトの平均的なスタイル
- マイニング結果の多数派が，
- insert_space_before_opening_brace_in_block → INSERT
- insert_space_after_opening_brace_in_array_initializer → INSERT
- insert_space_before_closing_brace_in_array_initializer → INSERT
- insert_space_before_closing_paren_in_cast → DO_NOT_INSERT
- などとなっている場合
```java=
public static void main(String[] args) {
int[] arr = { 3, 5, 2, 2, 3 };
for (int i = 0; i < arr.length; i++) {
if (arr[i] % 2 != 0) {
System.out.println((float)arr[i] / (float)arr[(i + 1) % arr.length]);
}
}
}
```
- 嫌いなスタイル
```java=
public static void main (String[] args)
{
int[] arr={ 3 ,5 ,2 ,2 ,3 } ;
for ( int i=0 ;i<arr.length ;i++ )
{
if ( arr[i]%2!=0 )
{
System.out.println( (float) arr[i]/(float) arr[( i+1 )%arr.length ] ) ;
}
}
}
```
### 実験手法3
#### 注目するスタイルの決定方法の観点を変える
- サンプルコードを小倉さんのツールに読み込ませて，得られた特徴の中から変更する特徴を選ぶ
#### pros
- 題材をどのような形にしても好きなスタイルと現実的なスタイルの差はかならず一定数のスタイルの変換を可能にする
#### cons
- 実際には全然揺れていないのに変えることになるスタイルがでてくる可能性がある
#### 実験題材のサンプル
```java=
public static void main(String[] args){
int[] arr = {3, 5, 2, 2, 3};
for(int i = 0; i < arr.length; i++){
if(arr[i] % 2 != 0){
System.out.println((float)arr[i] / (float)arr[(i + 1) % arr.length]);
}
}
}
```
```java=
public static void main
( String[] args)
{
int[] arr = {
3, 5, 2, 2, 3
};
for (int i= 0; i< arr.length; i++ ){
if (arr[i]% 2!= 0){
System.out.println((float) arr[i]/ (float) arr[(i+ 1)% arr.length]);
}
}
}
```
## C言語のコーディングスタイル
### 実験背景
- javaのスタイルには現実的に大きい差はほとんど生まれない
- では，カーニハンスタイルが強く根付いているC言語ならどうか？
### 実験手法
- C言語で揺れているスタイルを調査する
### pros
- 実験題材は簡単であるため，C特有の表現はほとんど出現しないため，javaを基本的に使用している人でも被験者になり得る
- javaよりはカーニハンスタイルが使われている可能性がある
### cons
- 小倉さんのツールはjava用のものであるため，そのまま使用するようなことはできない
- githubで少し探してみた結果，関数宣言時の`{`が改行されているか否かは揺れているが，`if`や`for`などの`{`の位置はあまり揺れていなかった
## お聞きしたいこと
- 論文のコードリーディングに関して難易度は操作した方がいいのか？
- 奈良高専へ伺う日程について
## memo
- 問題の重要さに関するストーリーが欲しい
- 理解に対してどういうメリットがあるかを明瞭に
---
- 時間の統制が必要
- 時間を2,3分で終わるタスクにして数を稼ぐべき
- コンソーラスを使うといい
---
- 文字数が寄与する題材ならなおよし
- ブラー処理をかけるような突飛な題材もいいかもしれない
---
- ソースコードの文法じゃないハイライトをつけたらどうなるのか？
- 極端なケースがあると確実に結果がでるので分かりやすそう
- グレーは日常的にみるレベルなので強くは反応しなさそう
---
- すべてを最悪の状態にするのもよい
- **やったほうがいいかも**
---
- リーディングの数は決めておくべき
- 6リード（1つ3分）5セット
---
- プロコンの問題をタスク化するのが客観性がありそう
---
- セットごとに題材は変える
- 2つのarrayをなにかしらコントロールする6リードで1セット
- そんなにややこしくない数学系の問題が定番
- Stringをいじる系も○
- 5セット作りたい
---
- 難易度はできるだけ同じぐらいにする
- 予備実験で解く時間を同じぐらいにするとか
- githubで実験セットとデータを匿名化したものを公開する
---
- ハイライトの既存研究との差はなんですかと聞かれたときの対処法を考える
---
- 視線でやる場合には題材を作るところから考えていく必要がある
- 視線は分析が難しい
- 視線装置は貸していただける
---
- 結果がでるかどうかが懸念材料
- なぜ非IDEでのリーディングにスコープをしぼったのか
- 不偏的な事象でCPRがどれだけ重要かを主張する
- 被験者実験でIDE以外で見せているとそれは大丈夫なのかと聞かれる
---
最悪ケースについて
- ランダムにハイライトを付けるやつ
- 結果がでそう
or
- すべてのファクターが×
- RQ4という形でおけそう
- ベストケース VS ワーストケース
or
- 両方やる
---
- 普段の環境に依存するのでアンケートをとる？
- 見慣れているかも？
- セットを繰り返していくことで相対的な不快間がでてきそう
---
- 極端なケースは一つ置くのが脳波の研究のスタンダード
- ハイライトランダム，変なフォント，めちゃくちゃ低画質も作る？
- フォント or 画質を捨てるのもあり
- どちらかといえば画質を捨てる
- ハイライト＊３，フォント＊２，最悪＊１，超最悪＊１：7リード
- 画質を捨てる
- フォントの影響を測る
- ランダムハイライトは完全にランダムで
## まとめ
- 非IDE
- ハイライト，フォント
- ハイライト3つは現実的+1
- フォント2つ+1
- 理解だけではなく印象への影響も調べたい
---
- アンケートをどうするかを考える
- 経験年数とか色々
- 色々な論文読めば書いてある
- ハイライトやフォントにどれだけこだわるかを被験者に聞く
- フルハイライトやグレーを普段どのくらいみるかの頻度を聞いておく
---
- 実験の練習でフルハイライトをみせておいて実験でのベースをつくっておく
- 意図的な順番にしてもいいかも
- 読むコードの順番は変えるほうがいいかも
- 中島さんに聞いてみるといい
- 非IDE上でコードを読むことに名前をつけておく
-
Sign in with Wallet
Connect another wallet