「ネスト」を含む日記 RSS

はてなキーワード: ネストとは

2017-05-26

プログラムってさ

エクセル関数使って色々な事出来るようになるみたいな感じなのかな?sum関数覚えて、count覚えて、ifをネストできるようになってちょっとテンション上がって。vlookupで一気に世界が開けて、sumproduct使って複数条件検索クリアして。一旦関数離れてピボットテーブル使えるようになってまた世界広がった気分に浸って。。そのうちそろそろ出来る事の限界が見え始めてきて、マクロに手を出して。最初操作を記録させて意味不明コード意味ひとつひとつ理解していって。そのうち記録で吐き出されるコードがクソ汚ねぇって気付いて。。。

で一つ疑問なんだけどさ、会社事務方やっててどんどん知識経験が付いて行くのは理解できるんだけど、「プログラマー」って、その職業につく前からプログラム書いてて、そういう仕事したいって思って就職したんだよね?いったいどういう必要に迫られてプログラムに手を出したの?

2016-12-21

http://anond.hatelabo.jp/20161221144317

上記の全ては夢であった。つまりネストされた夢であったのだ。

2016-12-06

比較級、最上級にする遊び

ニート、ニーター、ニーテストとか最近だとペンパイナッポーアッポーペナー、ペンパイナッポーアッポーネストとか

中学教師10年やってるんだけど毎年変わらずどのクラスでもこの遊びが蔓延する

なにが面白いのかチンプンカンプナーだよまじで

2016-11-24

プログラマーの思うこと

プログラマーから製造業社内SE転職した。

VBAわかりますけど(キリッ)みたいな人が作ったマクロを直すのが苦痛すぎる。

なんでもエクセルでやろうとすんな。

マスタのデータエクセルに貼り付けたものをつかってVBA組むな。

変数はご丁寧に一番先頭で宣言祭りコントロール名前が連番、無意味な処理、データ件数を取得するためだけに同じSQLをCOUNTにして実行、無意味ループに、ifの4段ネストメソッド名が不適切(checkXXX)、スコープは全部Public、定数の概念無し(マジックナンバー多すぎ問題)、型変換の概念無し(文字列数字にぶっこむ)、例外処理なし、その他突っ込みどころ多数

オブジェクト指向なにそれおいしいの状態コードがどんどん増えていく。

てめぇのエクセルスキルはよーーーーくわかったから、これ以上クソコード増やさないでくれ

2016-09-20

http://anond.hatelabo.jp/20160919121645

いいプログラムはif文をネストさせないし条件式もシンプルになる。というか極力if文を使わない。

から元のクソコード書いた奴が悪いんだよ。

あなたコードメンテナンスすることになる人が、 あなたの住所を知る強烈なサイコパスになりうるのを常に想定してコーディングしなさい」は至言だね。

2016-09-19

http://anond.hatelabo.jp/20160919121645

学者→初級者 あるある

ネスト深くなってもいいから&&と||を別にして正しく分岐させるべき。

こんなん設計が悪いってのが前提だけど。

SQLも実運用でサブクエリ使わないと抽出できないとかゼーンブ設計が腐ってんねん。

2016-03-21

コード憎んで人を憎まないなんてできるの?

そりゃね、リリースまで時間がないとか便利なライブラリを知らないとか事情があったのはわかる

でもほんと、ちょっとのことをするのに、何回も何回も何回も何回も何回も何回もコピペしたり

何回も何回も何回も何回も同じデータDBに問い合わせたり、ループしたりネスト深くしたり、

次に読む人に呪いでもかけてるのか、というコードを見ると、さすがに「誰が書いたんだこれ!?」と罵倒したくなる

今日日中学生でももっとまともなコード書くぞ

転職活動がんばったけど、入る前にちょっとでもいいからコード見せてくれるような習慣にならないかなー……面白くなってきたじゃねーの

2016-03-01

循環的複雑度ってさ

定量的に糞コードを測定するってスライドブクマされていて、見てみたらやっぱり循環的複雑度がでてたわ。

あれ、こういう話題でよく見るけど科学的根拠はないんだってな。

考案者のマッケーブに、科学的根拠は?って質問したら「役にたってるんだからいいじゃないか」みたいな答えしか帰ってこなかったって話を見たことある

まあ、たしか分岐ループが多くて複雑なコードバグが多くなるだろうけど、オレが「分岐は1点。ループは1.2点。ネストが一段で係数1.5を掛ける」みたいな増田係数みたいのを適当でっち上げても、バグの数と相関関係が出てくると思うんだよ。

あんツールを使わないと測定出来ない複雑なメトリクスでなくて「ネストはn段まで」とか「ifはn個まで」とか超簡単なルールでも対応できる程度のもんだと思ってる。

それなのに、Googleの超頭いい人達まであんオカルトを信じて「クソコードの測り方」みたいな数式を考えだしちゃってるわけでしょ。

なんかすごいよね。

2016-01-29

こんなEXCELマクロやばい

・textbox1から100まである。(名前を変えない)

グローバル変数がすべてセルに格納されている。

変数名はrange("c72")とか)

ソースを見ても処理がどうやって動いてるのか分からない。

セルチェンジイベントやformのloadイベントで処理がつながっていた。

(多分関数名でshift +F2とか使ったことがない)

・毎朝、自動で動かしたい→タイマーコントロール時間設定(帰る前に毎日設定。タスクは知らない)

DBデータを1件更新する→全件とってきて全件まわしながらIF文で更新データ判別

業務ロジックはvlookup

マクロを使って、dbからデータをシートに転記して、5回以上ネストしたvlookupやらiserrorやら

index関数がちりばめられたシートで報告書作成印刷マクロ

関数の書いてあるセルしか処理はできない。)

・すべてSUB

ネットからコピペしたfunctionはあるが、自作したfunction多分ない。

値を返すならどっかのセルに突っ込むだけ。

classなんてもってのほか

うちの会社はこんな感じのEXCELマクロによって動いてる。その数、数百本。

2016-01-21

正規表現便利すぎだろ

ネストとか出来れば、もっと助かるのと、実装が個々に微妙に変わるのさえ無ければもっと有り難いだがなぁ。

2016-01-20

バグ修正しましたって言えない

原因らしき1行を削除してビルドしなおしたらバグが消えたっぽいんだけど、

ifやforがネストしている上に条件式に複数グローバル変数が出てきててこれで直ったと言える自信が無い。

この1行を削除した結果他の箇所が壊れたとしても驚かないぞ……。

2015-09-29

はてブBNF手法が上がっておりますがここでBNF記法手法をご覧下さ

  • 株の方のBNF

http://tradenote.info/blog-entry-3.html


一般に、バッカスナウア記法正規表現では処理できないネスト階層記憶できるなどの根本的な差があります

これは正規表現が有限決定性オートマトンDFA)ないしε遷移と不特定の同種記号の遷移を用いる非決定性オートマトン(NFA)に基づいているのに対し、BNF記法での解析は必然的スタックを内部状態に持つからです。


代表的ものに以下の種類の構文解析処理方法が挙げられます


https://ja.wikipedia.org/wiki/%E5%86%8D%E5%B8%B0%E4%B8%8B%E9%99%8D%E6%A7%8B%E6%96%87%E8%A7%A3%E6%9E%90

https://ja.wikipedia.org/wiki/LL%E6%B3%95

これは左からトークンを走査して、導出する非終端記号を左から決定していくアルゴリズムです。

例えばA→A Bという構文規則があった場合に、Aの還元内でAを還元できるかどうか判定し続けて無限ループに陥ってしまい、いつまで経ってもBの判定に辿り着けません。これを左再帰といい、LLでは左再帰を直接扱う事ができません。

非終端記号の間接的還元考慮したはじめに現れる終端記号の集合(FIRST集合)を構築して上手く左再帰回避しなければなりません。

マッチングに用いる規則ベタ関数内部に再帰させながら順番に書いていくだけなので実装は容易です。


  • LR法

https://ja.wikipedia.org/wiki/LR%E6%B3%95

  • LALR法

https://ja.wikipedia.org/wiki/LALR%E6%B3%95

こちらは左からトークンを走査して、導出する非終端記号を右から構築するアルゴリズムです。

BNF構文規則から走査に相応するDFAを構築し、DFAの遷移を記憶しながらスタック状態push/pop構文解析を行います

なのでLL法にあるような左再帰を直接扱えないという欠点がなく、むしろスタックが簡潔になるため積極的に左再帰BNF記述を行った方が効率よく処理を進められます

LR法はDFAの大きさが巨大になるため、実用的ではないようです。

LALR法はLR法を改良したアルゴリズムで、扱える構文クラス範囲はLRよりも少し小さくなります現実的計算資源構文解析を行う事ができます

2015-09-07

結構最先端めな東京Web業界から地方SIer業界転職して3年経ったの

結構最先端めな東京Web業界から地方SIer業界転職して3年経ったのでそろそろ感じたカルチャーギャップをつらつらと書くよ。

転職理由はまあ家庭の事情ってやつなので割愛給料もやや減ぐらいで特筆することはないから割愛するよ。

⚪︎⚪︎部長とか呼ばないと怒られる

上司を呼ぶときは正しい肩書きを後ろにつけないと嫌な顔をされるよ。

前の会社では社長までさん付け普通に会話していたのでなかなか衝撃だった。

半沢直樹とかで見た世界がここに!みたいな。

昇進や降格で肩書きが変わると呼び方も最新のものにちゃんと変えないといけないから大変。

昇進ならまだ訂正する方が嬉しそうに訂正してくれるからいいが、降格した人を前の役職で呼ぶと気まずさがハンパない

当然メールの宛先にも肩書きを付けるので最初の宛先の羅列にすげー時間がかかるよ。

ザ・上司のオッサンみたいな人がいる。

スーツで太っててやたら偉そうで、何の仕事をしてるのかよく分からないがゴルフ情報にはやたら詳しいみたいなのが割といるよ。

その人たちにとって下々の人間は石ころみたいな存在らしく、ほとんど注意は払われない。

これもテレビドラマで見た!って感じだよ。

なかなか新鮮だった。

書く書類がとにかく多い

見積もりの確認からプロジェクトリスクから反省からレビューからテストエビデンスから

とにかくプログラムコード以外に書かなければいけない書類が多いよ。

さらに一つ一つに上司さらに上の人たちの印鑑必要なので時間がかかる。

上の人たちは書類を見て印鑑を押す仕事だけで1日のほとんどを奪われているんじゃねーかとか思うよ。

テレビドラマ以下略

詳細設計書とかいう詳細すぎる謎の書類

実際にコーディングをする前に、そのままプログラムに変換できるんじゃねーかレベルの詳細設計書を作らないといけない。(当然作成ツールExcelだよ!)

最初からコードで書く時間の5,6倍ぐらいの時間を使って、結局そのままコード自動変換はできないロジック日本語で書く。

当然簡単なテストも出来ないのでここでロジックの不備が見つかることはほとんどない。

ちなみに、実際のプログラミングは詳細設計書を写経するみたいなものなので全く面白くないよ。

一度上司にこの設計書の存在意義を聞いてみたら「誰でも実装保守ができるように」などという答えが返ってきたけど、実装ならこの設計書を書いている間に終わるし、コードを読めない人が保守するようなプロダクトには、恐ろしくて関わりたくないと思ったよ。

バージョン管理されてない案件とか

割愛

コードの読みやすさとか

まりにも文化が違う。300行ぐらいあるifブロックネストとか余裕。

割愛

Webサービス保守運営なのにテスト環境がないとか

割愛

自動テストとか

3年間で関わった案件で1度も実現できなかった。

割愛

同僚とか

エース級以外の人たちは向上心も無ければ危機感も無い。

何か問題があったらエース級の人に聞けばいいと思っている。

からエース級の人たちの心は常に暗黒を漂っているよ。

メソッド名が連番ID

色々な切り口で問題点を伝えたが「規約ですから」で取り付く島もなかったよ。

結局、呼び出す度にどういう処理をするのか毎回コメントを書くことになっていたのには笑った。

うそろそろ限界なのでやっぱり東京に行った方がいいのかなとか考えている毎月曜日だよ。

2015-05-18

循環的複雑度ってさ

サイクロマチック複雑度とかいうやつ。

ソースコードの複雑さを表す指数で、これが高いソースコードバグが多いって言われてるの。

なにげにネットを見てたら、批判的な文章をみたわ。

サイクロマチックの発案者に直接、科学的根拠あるのかって聞いたら「実際に役にたってるから(根拠は)いいだろ」みたいな返事らしいのな。

しかソースが複雑だったらバグは増えるだろうけど、それならツールを使わないと算出できないような複雑な指数をつかわなくても「ネストは○段まで」「サブルーチンは短く」「サブルーチンローカル変数は○個まで」みたいな単純なやり方でもいいよな。

サイクロマチックでなくても、見た目が複雑なソースなら大きくなる指数適当でっち上げても「この指数バグの発生件数は相関関係がある」って言えそうだよな。

サイクロマチックを目にするとき普通に役に立つ指数だって紹介されてるから、ただのオカルトだって知ってショックだわ。

2015-02-23

「循環的複雑度」って

http://weekly.ascii.jp/elem/000/000/306/306175/

ニコニコ生放送」のコードに、循環的複雑度が600を超えるメソッドがたくさん入っていることが判明したことがあった。循環的複雑度が75を超えるとバグの混入確率は98%、「いかなる変更も誤修正を生む」状態になると言われていて、要はニコニコ生放送は動いてるのが不思議なくらいバグがめちゃくちゃ出やすい状態だった。

循環的複雑度って科学的なメトリックスだと思ってる人がいっぱいいるけど、あれ根拠ないからな。はっきり言ってオカルト

分岐とかループが多い処理はバグやすいってだけ。

サブルーチンのなかにif文は何個以下とかネストの深さは何個とか、もっと単純な基準で「循環的複雑度がxx以下」と同じ効果をだせるはず。

2014-12-01

http://anond.hatelabo.jp/20141201005802

バグ出すか出さないか、ってのはそんなに重要じゃない。

つか、誰でもバグは出すだろ。バグさなプログラマなんて見たことねー。

プログラマってのは読めないプログラムを書くやつだ。

具体的に言えば、変数名、関数名に気を使わないやつだ。

ループの中身が1000行あってネストが4つ5つになってるのに疑問をもたねーやつだ。

読めるプログラムバグがあっても直しゃいいんだ。

バグがあって読めねープログラムゴミだ。捨てるしかない。

2014-08-12

http://anond.hatelabo.jp/20140812112643

プログラミング作法読みなおしてみた。

K&Rと同じく、基本省略スタイル推奨。

ただ、ifがネストした場合には、elseのぶら下がりがわかりづらくなるから、必ず中括弧書け、とも言ってる。

?  if (a)
?    if (b)
?  else
?    ...;

あと、ブコメでも指摘してる人がいるけど、どのスタイルに従うかはどうでもいいけど、一貫して同じスタイルで書くことはとても重要だ、とも。

既存プログラムが省略スタイルなら、追加コードも合わせるべきってことだねー。

既存コードがぐちゃぐちゃだったら、、、スキルが低い集団ってことだから、カッコ付けるスタイル修正してくほうがいいんじゃないかなー。

保守性・管理性が上がるPHPスマートコードレビュー12

1. 括弧の省略

PHPにおいてはif文やwhile文において、1行であれば括弧を省略することができます

<?php
if (...) 
  hoge();
while(...)
  hoge();

これは、保守性・管理性を上げたいのであればやってはいけません。括弧がつくことで視認性が下がることなどありません。むしろインデントに騙されてしまい、ミスが増えます。例えば下の例です。

<?php
$a=0;
$b=0;
while ($a < 10)
  $a++;
  $b++;

さて、このとき $a はいくつですか? $b はいくつですか?

答えは $a が 10、 $b は 1 です。$b は while のスコープにはないので、ループしません。

括弧でくくられていればこのようなミスを防げます。括弧はきちんと書きましょう。

2. 三項演算子

ネストしすぎると可読性が損なわれるため注意が必要ですが、うまく使うとスマートに書けます。うまく活用しましょう。

3. switch

条件分岐が多い時にうまく使いましょう。

ただし if 文で素直に書いた方が速度は速いという噂もあります

実用上の違いはほとんどありませんので、チームの方針に従いましょう。

4. ループ

PHP にはループ制御構文が用意されています。主に下記の3つを用途にあわせてうまく使い分けましょう。他にもループに関する構文や関数はありますが、基本的には下記で事足りるでしょう。

  1. for

主に回数でループさせたい場合は for 文を利用するといいでしょう。

例えば、10回同じ処理をする場合は下記のように書きます

<?php
for ($i=0; $i<10; $i++) {
  // 



  
  

http://anond.hatelabo.jp/20140812145234

横だけど、

switch-caseもどきのif elseが多段でネストしているロジックの時にcaseの中身を

private voidにしないと1000行ぐらいあるケースの場合

private void __whatdo();

という使い方になるのでは? あまりあるケースではないけど、関数テーブル一発で飛べない場合には出てくるのでは?private void


if( a ){
    if(b) {
        __whatdo_A();
    }else if(c){
        __whatdo_B();
    }else{
        __whatdo_C();
    }
}else if(d){
    __whatdo_D();
}else{
    __whatdo_E();
}

このパターンの複雑なばあい

__whatdo_Eを直接呼ばれたくないけど、関数化しないと読めたもんじゃないという場合にはprivate void()になる。

http://anond.hatelabo.jp/20140812132823

せやな。「ネストすんな」を言い続けてたらprivate void()でソースを埋め尽くされたこともあるし、もっと大枠で語らないかんな。

http://anond.hatelabo.jp/20140812112643

中括弧は、プログラミングを覚えて1年くらいの段階で絶対に付けるようになって今に至ってる。

ブロック内がシングルステートメントなら無くてもいいんだが、後で処理を追加するのにいちいち中括弧を付け足すことが頻出して、だったら先に書いとけばいいや、と。

実際に中括弧を付け足すのを忘れたり、if行との間に一行空けてしまう(改行でステートメント区切り言語)という事故も起こしたし。

中が一行であるという保証はどこにもないのに、一行しか書けない記法を使うということにナンセンスさも感じる。

今どきの言語はそもそも中括弧をなくすという方法をとっているが、合理性を感じる。ただ抵抗感はある。

あと中括弧とネスト構造を一緒くたに考えるのは間違いだよ>別ツリー

http://anond.hatelabo.jp/20140812124757

その程度のことで、全体には影響しないって。

アルゴリズムのほうがよほど影響するってばよ。

 

コードネスト云々は、宗教論争だが

アルゴリズムの選択は下手すりゃデスマーチだ。

http://anond.hatelabo.jp/20140812124145

ネストしない中カッコ自体があり得ねえんだよ。

勿論中カッコ無しの糞ネスト(漏れ三項演算子でよくやる)も大概だが、

大体は中カッコを省く努力をすればコードスッキリするもんだ。

コードを省くのはフォーマッタではなかなかやってくれない

(賢いIDEだとやってくれるのもある)けど、カッコ付けるの位はフォーマッタで余裕なんだ。

機械に頼れる部分は全力で頼りに行くべき。

http://anond.hatelabo.jp/20140812123017

中括弧の省略とネストの深さは関係ねーだろって。

「中括弧は省略しない」「ネストは深くしない」全く別の話だし両立するだろ。

中括弧が無くたってネストが深いのは糞コードだろうが。

#include<stdio.h>

int main() {
    int a = 1;
    int b = 0;
    if (a)
        if (b)
            printf("Hello");
        else
            printf("Howdy");
}

http://anond.hatelabo.jp/20140812122354

なんでわかんねーんだよ。「中カッコはなるべく入れましょう」って思想だと、ifネストしてても「だってそう教わりましたしおすし」っていう考え方になるから、なかなか洗練されたコードに行きつきづらいんだよ。

「中カッコはなるべく外せ」って思想なら、「なぜここに中カッコがあるんだ? 省略白」って言えて、指導が出来るだろ。

二律背反を防ぐためのもんだよ。

省略され切った後にフォーマッタ起動すれば適度に見やすい形に変わるから、そうしたほうがプロジェクト的にもええべ。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん