「命名規則」を含む日記 RSS

はてなキーワード: 命名規則とは

2017-05-12

http://anond.hatelabo.jp/20170511230227

ホワイトカラーではこのやり方は適さないと仰る方もいます

 ・使用するツール書類の書式と提出先、命名規則などの社内ルール

 ・ルーチン化されている場合はその手順と注意点

といった、この会社特有の(=部外者には知りえない)情報を教えて、道筋を立てた上で

専門スキル必要フェーズプログラミングなど)になったら「自分で考えろ」という話かと思いました

具体例:

http://anond.hatelabo.jp/20170512081457

2015-07-24

生産性寄与しないコーディング規約

多人数でシステム開発をする場合統一性があったほうが読みやすい」なんて理由で、言語別・組織別・プロジェクト別にコーディング規約があるものだけど、そんなに乱立しているなら個人別の規約があっても何も問題はないはず。

これは詭弁だろうか? でも個人的な開発や、開発中に読むサンプルコードも含めて、自分がいくつのコーディング規約に関わっているか考えてみると、個人から見た統一性は失われているわけだ。


「整理」と「整頓」という言葉がある。前者は秩序立てること、後者は見た目を揃えること。本を分野別・用途別に並べれば整理、大きさ別に並べれば整頓となる。

コーディング規約は専ら整頓のルール。読めない人にとって「きれい」に見せるルール

コード意味に関わらないからこそ、実装後に修正ができる。さもなければ、正しいコード自然コーディング規約に適うものになるはず。コードの正しさと無関係から、正しいコードでもコーディング規約違反だったり、コード理解していない人でも指摘できたりする。

コーディング規約を作って発表する人もいる。でもそれがどれだけ生産性を上げるかについては考えていない。作りっぱなし。そんなルールに「あとで読むタグを付ける人たちは、プログラミング言語表現の幅があることを欠点と捉えているのだろうか。本来そういったルールを作っていいのは言語の考案者だけのはずなのに。


一方で、整頓に当てはまらないルールもある。例えば命名規則

あるにはあるけど、言語に組み込まれているライブラリと同じ規則ベストなので、やっぱり規約は要らない。


コーディング規約のうちで役に立つの用語集くらい。

あとは自己満足

2015-06-24

弊社(独立系SIer)の紹介

皆様の入社を、心よりお待ちしております

安心と信頼のウォーターフォール

設計3ヶ月、開発1週間

技術が育たない

→とにかく動かせ!の動けば良いの精神

試験修正に3ヶ月

ソーススパゲッティ化で可読性皆無

仕様変更設計からやり直し

→以下無限ループ

納期に追われて

命名規則?そんなのやってられっか!

ローマ字メソッド名多発、日本語でおk

効率の良いコーディング?知るかんなもん!

ソーススパゲッ(ry

→誰だこのコードを書いたやつ、ぶっ殺してやる!

あなたです

現調でてんやわんや

→あれ?動かねぇぞ・・・

ソースを見るもスパゲッティイミフ

→とりあえずの応急措置ソースさらゴミ

デグレード発生

→とりあえずの応急措置でs(ry

→以下無限ループ

そもそもの発端は

経営陣「利益上げろ!とにかく働かせろ!」

デスマ危険を察し退職者急増

→少ないメンバで多くの案件を処理、追いつかない、フリーズ

デスマ突入ハイパー残業タイム

経営陣「(数字だけ見て)利益出てねぇぞ!働かせろ!」

さら案件を受注

デスマカンシーズン突入ハイパー徹夜タイム

経営陣はホビロン

営業「言語VB.NETでよろしいでしょうか」

→みんな大好きVB

技術が育たない

→そもそも多言語学習する意欲を持っていない

この先生きのこれない

新人派遣

OJT?そんな余裕はねぇよ

新人入社1週間で派遣先

→1ヶ月も経たない内に追い返される

2015-01-13

http://anond.hatelabo.jp/20150113134116

クラス継承は常に単一継承なんだよ。インターフェースは多重に継承できるんだよ。無いと結構困るだろ?

Pythonではクラスは多重継承できるよ。

そもそも、静的型付け言語みたいに、インターフェイスを型で揃える必要ないけど(ダックタピング)。

普通にアクセサメソッド作るやろ。

PHPとかだとマジックメソッドgetなんちゃら()をプロパティのようにobj->変数アクセスしたりする。

アクセサなしのプログラミングpythonでの常識なのかもしれないが、そんなん変数いつ壊すかわからんから怖いだろ…

命名規則で充分だろ。Pythonでは'_'を先頭につけるのが標準。

マジックメソッドPythonにもある。

他、pythonには__init__.pyも含めた「簡素ではない独自ルール」が存外多いってのを問題視しとんのや。

少なからず、初心者向けじゃないぞアレ。無駄に躓くポイントが多い。

Javaビルドのほうが遥かにめんどくさいじゃん。Eclipse無しに複数ファイルコンパイルとか、プロでもできないやつ多いんじゃね?

Python初心者向けじゃないのは、日本語でぐぐった時の情報が少ないことかな。

2014-07-19

平成生まれインターネットアングラ編)

我が家に初めてパソコンが来たのは2006年頃。FMVのよくわからないモデル

当時は住んでいるところにまだADSLしか引かれてなかったのでADSL回線

動画ストリーミングのはじまり

俺がインターネットをし始めた年前後インターネット上ではYouTubeが生まれたりと動画共有サービス流行っていた。いまでこそ著作権コンテンツはすぐに削除されてしまうが、当時はアニメがそのままあげられていたし、VeohとかStage6とか他のストリーミングサイトでもアニメが見放題だった。俺はその頃放送されていた「涼宮ハルヒの憂鬱」を見てからアニメにハマってしまったクチだ。

しかし当時は回線もあまり速くない。動画を見ていたらしばしばロード待ちになっていたし。そもそもまだ地上波ほとんどがSD画質だったわけで、今のように高画質なHD動画なんてなかった。というか俺の家にはHDの画面がなかった(1280x1024とか1024x786)。

らきすたニコニコ動画

ネットである時期からやたらニコニコ動画サイトに誘導されることが多くなった。俺はβ時代は知らないがγにハゲおっさん選挙演説動画を教えられてアカウントを取得した。当時はまだニコニコ動画サーバが貧弱だったため、会員登録してもその先で「ID開放待ち」というのが待っていた。ようやくIDが開放されてサイトを見てみると「らきすた」というアニメ動画が上がっていたので見てみるとおもしろい。毎週平日の朝7時ぐらいにあげられるため、学校にいく前にらきすたを見るのが習慣となった。

当時はまだニコニコ動画ではH.264エンコード採用してなかったため、VP6を使っていたらしいが上下反転させたりエンコードにめちゃくちゃ時間がかかったりと、当時上げていた人も大変だったんだろうなとおもう。

P2P

ニコニコ動画と平行してぐらいかP2Pにも手を染めた。Winnyウイルス問題が起きた後ぐらいであたか、その頃ニコニコ動画でも流石にアニメアップロード浄化作戦が始まっていて、地方である俺はアニメを見る方法がなくなっていた。その代替策として当時ネットの友人に教えてもらったのがPerfect DarkというP2Pソフトだった。俺にとっては夢の様なソフトで、アニメがいくらでも転がっていてしかHDの高画質(しかしその動画DVDTV放送をアプコンしただけ)。糞遅いADSL回線でがんばっていろんなアニメダウンロードしていた。

他にも同人誌エロゲーというジャンルを知ったのもこの時。「(C72)[作者名]作品名(元ネタ).rar」みたいな非常に効率化されたファイル命名規則、.rarかいうみたこともなかった拡張子、.isoDaemon Toolsロードしたら読めるなんていうのを知る機会は多分こんなことしてないと得られないんじゃないか。

まとめ

そんなことしてたらなんだかんだで成人してしまい、今ではこういうことをするリスク私生活に影響を及ぼしそうでそういうことは一切していないわけだが、当時やっていたことが少なからず今の生活で生きている気がする。

2014-02-28

去年はじめから現在まで

2013年1月か2月

プログラミング経験、ほぼ皆無。

HTMLCSS, JavaScriptちょっとだけ分かる

dotinstallとか見てブラウザタイマー作ってわーいって喜んでるくらいのスキル感。

プログラミング勉強したい

勉強したいけどスクールとかはお金かかるから嫌だ

→本を買ってやるのは安上がりだけど途中で挫折しそう

→じゃあお金稼ぎながら学んだらいいんじゃ

プログラマバイト探そう

求人サイトで見つけて応募してみる

経験でも大丈夫らしい

バイト始めることになった

バイト始まる

はじめは研修アルゴリズムPHPについて

課題を出されて、できたら業務に入れる

フレームワーク使って指定されたwebサービスをつくる

基本自分の力でつくる。放置される

誰も教えてくれない

今思うと初心者やらせるのはなかなかハード

ググってググってググりまくる

他のできる子はさらさらっと1週間くらいで終える

ひーひー言いながら2~3週間でなんとか終えた

この期間、ほとんどプログラミング以外のことしてない

なんとかなった

3月4月

PHPドキュメントを読む習慣がつく

ググってコードコピペして動かしてみる、という段階

動くと楽しい 分かると楽しい

このときくらいにパーフェクトPHPを読んだ。FWは、つくれる!

FWがなんたるかをやっと理解し始める

あーようするにURLを受け取って振り分けたり、DBからデータ引っ張ってきて画面に表示させたりするのね

分かった気になる←分かってない

HTTPリクエストについて気にしだした

GET/POSTでごにょごにょすればいいんだね楽勝だわ←全然分かってない

フレームワークはいくつも種類があることを知る

このころ、Sinatraという言葉を小耳に挟む。支那虎?

5月6月

FuelPHPを聞きかじって、何をトチ狂ったのか在宅でwebサービス受託をやる

まあ良い経験になった

フレームワークいくつかやって、web開発のいろんな概念tipsがたくさん頭に入ってきて、

あーあれかーくらいには思えるようになった

DBCRUD操作, ORM, DBマイグレーション, RESTfulとは, コマンドラインコード生成,認証周りのプラクティス ...

7月くらい

さて、バイトが本格的?になってくる

一人で開発 責任おもい

機能追加のタスク

ごく一般的機能

でもなんか躓いた。

書いたコードに自信が持てない

これでいいのか不安になって手が進まない

やっぱり自分で考えて経験したことのないことはなかなか難しい

DBのテーブル構成を理解するにも骨が折れた 命名規則大事

セキュリティで手直しはたくさんもらった

フレームワークにはDB操作ライブラリがちゃんとついてるのにそれ見ずに自分SQL組み立てて案の定エスケープしてないし、とか

必要ないところでCSRF対策してるし、とか

でも、なんとか完成させた

プッシュして、マージされて、できちんと本番環境で動いてる。やったね。

8月9月

Rubyを知った

PHPと違って()が殆ど無いし、;ないし、do~endとか何だよって感じだった。

ちょっとだけ触ってみた。使いやす

Railsも知った

それからは空いている時間の大半をRubyRailsにつぎ込んだ

まずはRailsTutorialをやってみた

テスト周りでつまづいたけどなんとか終わらせた

dotinstallやらミニツクやら、検索して出てきた記事・チュートリアルはとりあえず手をつけて学んだ

はじめはRuby理解せずにRailsをやっていたけど、すぐにRuby自体に興味が出てきた

はじめてのRuby・はじめてのプログラミング・たのしRubyプログラミング言語Ruby... 入門系の本を乱読した

PHPでさんざん苦労していたからか、Rubyオブジェクト指向を学ぶとなんの無理もなく頭に入ってきた

Rubyドキュメントの読み方を覚えた

その後、パーフェクトRubyで標準ライブラリやらGemやらSinatra支那虎じゃなかった)やらについて学んだり、

メタプログラミングRubyで黒魔術を学んだりした。巻頭のMatz言葉痺れたなー

バイトのほうも何とかこなせるようになってきた 成長すげー

9月10月11月

Vagrantをかじる

インフラ・ミドルネットワーク周りに興味がでてくる

AWSでいろいろ遊ぶ

メタプログラミングRubyは断続的に2~3回ほど読み返す

Rubyってほんと使ってて楽しい

webスクレイピングとか検索APIとか使ってムフフ画像をアハーンしたりして遊んでた

11月12月

Rubyと名のつく書籍を読みあさる

Ruby言語をつくろうだの、スクリプティングを極めようだの、JavaRubyがどうだの。

メタプログラミングだの、デザインパターンだの、テストだの、リファクタリングだの。

借りられる本は借りて済ませた。全部買ってると破産する

他にもRubyとつかない本もいろいろ。

達人プログラマーは途中で挫折した。そのうちもう一度読む

プログラマが知りたい97の何とか。いい本

Ruby関数オブジェクトからのつながりで関数型プログラミングにも手が伸びる

OOPと全く違う。

2014年1月2月

就活はじめるよー

まあ、エンジニア枠で探すことにする

エントリーめんどくさい

ので、1社受けて落ちたら次の会社エントリーするという作戦にした

無計画玉砕作戦

はいえ、なんとかなると思ってやってく

気を揉む期間

いろいろな会社採用ページ眺めていると気になること

入ってやる仕事の内容が分からない

やたらパララックスつかってゴテゴテにしてるわりに、何が言いたいのか伝わってこない

せめてよく使ってる言語くらいはのっけておいて欲しい。

気になる会社はいろいろ調べる

で、1社選んで応募して、選考が始まった

面接、失敗したなと思ったところもあったが

嘘つかない

知らないことを知ってるように話さな

は通せたので良かったと思う。

で、進んでいって最終面接。これもなんかよく分からないうちに終わってた

相手が適宜フォロー入れて話しやすいようにしてくれたのは覚えてる

うん、ぜひ当社にご入社いただけたらと思いますとのこと。やったね。

から気になってた会社ではあった。勝手リスペクトしてた会社

自分が憧れてる技術者さんたちが在籍してる会社でこれから働くことができる

いろいろと運が良かった。嬉しい

他の会社はどうしようかな。

受けてみたい気もするけれど、エントリーがめんどくさい

続けるかどうかは未定だけど、ひとまず休憩することにする

今は、関数型言語についての本買って読んでる。関数型、Rubyに劣らず楽しい

2013-12-25

ここが凄いよ!WordPressテーマ「STINGER」 #Stinger-WP

WordPressテーマ「STINGER」がアツいらしい!

http://stinger3.com/

Advent Calendarも作成されてるし、これは使えそうだぞ~!!11

http://www.adventar.org/calendars/90

えぇ。色々とマンセーされてるみたいだからダウンロードしてみました

   これはヒドい・・・

一言で言うなら、「コピペして作りました!」

(コーディングルール?何それ?タブとスペース?何か違うの?)

いや別にコピペして作ったのを配布するのは悪くないよ

それすら出来ない人間からしたら有りがたいものだと思うしさ

たださ、これの製作者ってPHP・・いやJavaScriptすら分かってないんじゃねーの?

ひっどいわ。コメントすらまともに書けてねーんだ

<?php // コメント // ?>

死ぬ気か?

挙げだしたらキリがないので

あとはダウンロードして確認することをお勧めする

> STINGERは、WordPress初心者の方でも簡単にSEOに強く、アフィリエイトも出来るテンプレートです。

初心者の人に教えてあげたいけど、これよりもっといいのあるよ、ただそれはSTINGERではない

SEO効果があったとか書いてるブログは何をもって効果があったとしてるか知らんが

SEOなんてようは中身だろ。もちろんソースも関わってくるけどSTINGER見た限りでは

デフォルトテーマの方がいいレベル

から要望(使わないけど)

ディレクトリ構成ぐらいきちんとしろよ(逆に何で /images だけあんの?)

・開発環境に入ってるデフォルトフォーマッターでいいかフォーマットしてくれ

ファイル命名規則ぐらいちゃんとしたら?("itiran"って何だよ。イーティランって英語あんのかと思ったわ)

・もうコピペはやめろ

コピペで良い物を作りあげるのもエンジニアとしては必要とされる事かもしれんが

こんな危ないコピペテーマを、「初心者でも安心」と言わんばかりのキャッチコピーをうたって配布してんだからタチが悪いわ。

製作者さんよ。

これさ、不具合が出て直せんの?

そんな危ないコードを配布してるのに危機感もったらどうなんだ?

ウイルスばら撒いてるようなもんだぞ?

追記:

http://anond.hatelabo.jp/20131222235456

やっぱり変なのも沸いてるみたい

簡単に拡散して貰えるからって乗っかってくる奴らも多いんだろうな。

リンク先のブログが月間30万アクセスとか眉つばも良い所だわ。

100歩譲っても運営者のアクセスが30万とかそんな感じ。

2013-08-01

失敗した業者を庇うクライアントの心情とは

Web制作業をしてるんだが、最近「別の業者に依頼したけど、効果が出ないので御社でお願いします」みたいな依頼が増えてきた気がする。まぁ、料金だけ見て判断したから痛い目あったんだな~とは思うんだけど、クライアントはなぜかその業者を庇う。「効果は出ませんでしたが、担当者は凄く良い人でした」みたいな事を言う。だったら、その良い人に任せて効果が出るように努力してもらえば良い話だと思うのだが。

このクライアント以外にも「最近仕事が忙しいようで連絡が滞りがちになっちゃったんです。大変みたいなので、御社に依頼しました」とか「SNSとかスマホとか最近Webに関する事は知らないって言われました。仕方ないですよねー」みたいに言う。

俺が客なら「こっちが先に契約してるのに、忙しいから出来ないってどういうこと!?」「SNSスマホぐらい、触りだけでも知っとけよ…」って思うんだけど、そんな文句はひとつも言わずに、とにかくその業者を庇う。

でも、その業者が作ったサイトを見たら、コーディング適当だし、命名規則にも沿っていない。明らかに”ホームページ制作ソフトで見た目だけ重視してホームページ作りました”って感じだ。明らかに手抜きか、知識がない素人作品で、非常に引き継ぐのが面倒なものになってる。

から、「サイトの中身見たけど、めちゃくちゃでしたよ」って言うんだけど、やっぱり「一生懸命やってくれたので…」と庇う。俺の性格が悪いだけだろうか。

2013-07-29

http://anond.hatelabo.jp/20130729133108

最終的なイメージはてなみたいなサイトを作りたいとか)はあっても、それを実現させるまでの過程が難しいからね。コーディングひとつとっても、構成や命名規則なんかで悩むことが多いし。

2012-08-16

http://anond.hatelabo.jp/20120816143405

前半分と、後ろ半分は言いたいことが違うから

位置エネルギースカラーであると考えるほうが、多くの場合に便利である

に突っ込まれた。という事でいい?

位置エネルギー というか ポテンシャル 単体は 定義しようと思えば テンソルでもベクターでもスカラーでも そのいずれでも定義可能であるが(ベクトルポテンシャル存在している)

エネルギー交換の法則ベースに考えると、ポテンシャルエネルギースカラーであるほうが便利であるからポテンシャルエネルギー位置エネルギーとしたんだなぁ。という話。(和訳したと言うよりもスカラーポテンシャルが持つエネルギーポテンシャルエネルギーと命名した)

 

ポテンシャルエネルギーは スカラーポテンシャルベクターポテンシャルがある(らしい)し ベクターテンソルと考えることにも非合理性はないのに

なぜ、ポテンシャルエネルギーであるところのポテンシャルエネルギー位置エネルギーを わざわざスカラー量に限定したのか? という話で 繰り返しになるけど エネルギー交換の法則ベース にしているんだなぁと。

思った ということ。

 

まり僕は ポテンシャルエネルギーと ポテンシャルエネルギーの違いがわからなかったけど、うっすらわかって、まだまだ趣味の範囲で勉強するよという話。(用語が不正確ですまんね)

逆に言えば、仮に 運動エネルギーベクターで表す社会があったとしたら、位置エネルギーベクター量だった可能性が高いんだなぁ。という 話。

 

命名規則の話かね。

2011-11-07

2010/05/16 23:40

こんにちは。昨日会った者です(これで特定するには情報不足だけど、まあわかるよね)。

で「幅優先探索でやる」という方針自体はいいと思うし、データ構造の作り方も基本は押さえていると思います(斜め読みしかしてませんが)。

ただ、コーディングの発想が「C で作る」という大方針から見て、少しちぐはぐな印象も受けますデータ構造設計操作の部分、汎用のライブラリを作ろうというのならあれでもいいと思うのですが、わざわざ汎用のライブラリを使わず自分で専用の道具を一から作ろうというのなら、問題の性質を考慮して能率良くやることが大事です

ところが、ここに載っているコードを見ると、見かけが C らしくなく、C++Java の劣化版のような印象を受けます記法マクロ大文字化しない、ルーチン名を大文字で始めるなど)だけの問題ではなく、データ構造設計思想が「C で書く」という方針と矛盾しているように見えます

もう少し具体的に言うと、そもそも C というのは現在 Web 系の世界などで流行スクリプト言語類とは逆で、汎用言語でありながら低レベルハードウェアに近い)処理が簡単にできることに特色があります。つまり組み込みを想定してプラットフォーム依存コードを書いたり、ハードウェアの特性を考慮して低レベル最適化をやりたいというときに適しています

そこでこの問題ですが、これを C でやるということは、処理速度や使用メモリ量の最適化が要求される状況、つまり迷路の大きさが途方もなく大きいような状況を想定すべきですもっと言ってしまえばこの問題、たとえば画像処理などで似たような発想が要求されることがあります。このため、どうすれば時間のかかる処理を切りつめることができるかを考えてやらねばなりません。

このプログラム場合時間のかかる処理の代表格である malloc() が大量に使われています。これはいかにもまずいです。このような大量データを処理する場合の定石は、あらかじめ必要なだけメモリを確保しておいて、自分で割り当てることです。具体的には、必要と想定される量だけメモリ配列の形でどかっと確保しておいて、配列インデックスポインタ代わりに使います。そして、足りなくなったら倍々のような感じでメモリを realloc() してやればよいのです

なお、そのような観点で言って、木の各節点の子の数は高々 4 (スタート地点が内点でないとすれば 3)であることを使っていることはよいと思います。ここで「子のリスト」とかを作ってしまっていたらこれはもうアホもいいところですから(容量の節約にすらなりません)。

そんな感じでしょうか。

とにかく、この手の問題は、アルゴリズムさえわかっていれば可読性もヘッタクレもないので、「短く書く」というような表層的なことよりも、何が求められているのかをよく考えて、柔軟に設計思想を考えることが大事だと思います

2010/05/17 13:54

Oさんですね。専門的なコメントありがとうございます!cで書くと言いつつObjective-Cっぽい発想で書いていました。マクロの命名もその影響で、関数Image Magickなどに似た命名規則になっている気がします。mallocを使いすぎると時間がかかるということは全然意識していませんでした。今度作るときメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました!

2010/11/18 23:56

はいわゆる「正規表現」は形式言語理論でいう正規表現ではないんだけどね……(ぼそっ)

2011-01-06

http://anond.hatelabo.jp/20110105194406

たぶん、元増田さんは、言語仕様としてのBOOL値を独自定義するなと言いたかったのだろうけれど。

そうではなくて、独自規格から始まったものが後日改変されて、正しく定義され規格化された場合、その日以後の新プロジェクトはその規格に従ってくれという事。(例外もあるだろうが)

当初true/falseという物はなかったが のちのちC++などのために定義された その定義の中には if(false){がelse節になるという自明の理が含まれている。

であるならば、falseという名前を含んだものがifでthen節になるルールを、後発規格ができたあとに作るな。という事。

そういうものが必要であるならば、ON/OFFであるとかActive/Inactiveであるとか、命名規則が矛盾しないルールを作って、規格化されたルールとまぎらわしいルールを作るのは、誤用の観点から、なぜ、そんな事をするのか?害悪じゃないのか?という事。

 

なぜならば、後発規格で定義された標準仕様に反するから新規参入メンバーが混乱し、同一視した結果、意図しない潜在バグが発生するおそれもあり、教育コストの面からデメリットしか無く、経済メリットが挙げられない。コンパチビリティーで先発規格に合わせるのは除外して。(MS定義のFALSEなど、旧システムのfalseは仕方がない)

同様に int,short,long の定義は short<long でありint は適宜最適な長さ という意味なので my_longなどを独自定義せずに 4バイトが欲しいならDWORD(先発規格)かint32_tを定義するか使え</p>

いつまで、my_longを定義しているんだ!いい加減 規格に対応しろ という事。

 

10ライブラリを呼び出します。lib1_true lib2_true lib3_true lib4_true ・・・・ lib1がtrueだったときにlib2にtrueを渡して・・・その結果をlib3に・・・載せ替えて・・・ってどんだけ、コンパチの確認を目視でしなきゃならんのだと・・・。

各個人、各会社で独自仕様しかも、C/C++の規格と紛らわしいとか、やめてくれ。可能なかぎりC/C++の規格で使えるものは使ってくれよ。と

2010-07-20

http://anond.hatelabo.jp/20100719012918

この世にはね、掛け算できないものなど、なにひとつないのだよ、

とは申しますけどね。

命名規則は以下のとおり。

市電が通っていた通りのほうが先に来る。

・縦横両方に市電が通っていた場合市電が先に開通した通りのほうが先に来る。

ですので

五条御池が受けな理由

 市電敷設ではなく、建物疎開で拡幅されたので市電停留所がない

・千本が攻めな理由

 明治末/大正初期に東西方向に先駆けて敷設されたため

七条千本な理由

 三条通以南の千本通には市電が通っていないため(大宮通シフト

四条堀川な理由

 北野線四条堀川以南には行かないため(西洞院通りにシフト

西大路最強な理由

 四条通大宮以西はトロリーバスだったため

トロリーバスになった理由

 先に嵐電が開通していたため

たぶんこの解釈でも例外があるだろうけど、

こう考えるとちゃんとした法則性がある、ということです。

単なる年上攻め?

2010-02-24

http://anond.hatelabo.jp/20100224224248

最初はあんまり気にせず、とにかくたくさん書いて読めば良いと思う。

結果が同じなら、無理に難しく書く必要なんてまったく無いし。

何か良く知らないけど、無理に難しく書くことに凝る人とかいるけど、あまり意味ないし。

有名なコードをたくさん読んでいると、そこに流れる共通マインドみたいなものが感じられるから、

その中でコレが良いって思ったものを取り入れれば良いよ。

作法とかなんとか、言う人がいるけど、大抵は・・・宗教だし。

でもなんだろう、なんでもいいから、命名規則はしっかりポリシーを持って欲しいと思う。それがアレば、あとはなんでもいいや。

 

その代わり丁寧に作って欲しい。考慮漏れとか、ちゃんと調べてないとか、エラーハンドリング中途半端とか、そういう方がよっぽど問題。

1行1行意味を考えて、丁寧にサボらず作っていれば実力は上がっていくよ。

給料は上がらないかも知れないけどw。

 

これは言ったらいけないのかも知れないけど、今の日本プログラム業界の大半は、プログラム技術を身につけるより、転職するかポジション争いをするか、中間搾取できる会社に行くかそんな方が給料の上がりは速いきがする。でも、それなら、最初から証券会社にでも務めた方がマシという物。

技術職を目指すなら、とにかく基本は丁寧に、真心込めて。ただし、技術の安売りはしない。コレかと思ってる。

2009-05-21

http://anond.hatelabo.jp/20090521120738

プログラムの振る舞いさえ見れば、何をしているかなんて一目瞭然だから、

変数命名規則なんて適当でもいいんだよ、と言われれば?

2009-05-20

http://anond.hatelabo.jp/20090519185138

元増田です。

てきとーに書いた記事にトラバくれてありがとう

以下、所感です。


命名規則曖昧

ある分かりやすい規則に基づいて変数名を決めるというルールが徹底されていないこと=整合性が取られていないことが問題なのでは?

たすかに。

だがしかし命名規則をかっちり決めることができないからこそ、

「原則略さない」とりいう分かりやすい規則を規定すればチーム内、及び引き継ぎ後のコード可視性は大幅にアップするのではないだろうか。

文字数はどの程度まで?

変数名60文字とかになってもよいと?

ぎりぎり25文字くらい?

単語を全部並べるというか、重要単語をピックアップして並べる方がいいね。

訂正します。

コピペコーディングのすゝめ

CUI環境コーディングする人はごめん)

タイプ数を減らしたいでござる

とにかく、変数名、メソッド名は原則全部コピペorIDEの補完機能を使う。

これだけで、タイプ数・タイポ数は圧倒的に減らせる。

クリップボード関係フリーソフトあわせるとその効果は飛躍的に上がるよ!

2009-05-16

http://anond.hatelabo.jp/20090516110528

ソースが汚いと知ってる言語でも読めない。キレイだと知らない言語でも少し読める。

個人の経験から行くと、

コーディング規約が決められ守られている/きっちり設計されているプロジェクトコードは読み易い。

そうでないソースは読みにくい。

この辺りがきっちりしてると読み易い。

  1. 変数/関数命名規則があって、それが守られている。
  2. 関数名と処理内容が一致していること
  3. 処理の階層がきっちり設計されている。(たとえば、排他処理でmain()でロックかけたら、main()ロック解放する)

実際、長年使ってこられた古いソースなのどは読み込めば読み込むほど、過去どういうバグがあって、どういう経緯でそういう書き方になったのかが見えてくる。

そうかな?古いプロジェクトコード担当コロコロかわっているのか、

書き方が統一的でなくて読みにくいこと多いけどな。

あとから問題が発覚して、お客さまの業務の影響あたえるので場当たり的な修正を実施。

急いでリリースしているのでコメント不十分で、後付けで保守書が作られている。

コードだけ見てもわけわからんけど、保守書見てやっと意味分かるとか。

ログイン ユーザー登録
ようこそ ゲスト さん