javascriptでテーブル行挿入処理を雑に実装する
( ´＿ゝ｀)ノシ
yoshitiaです。
phpの現場が忙しく、
1年の6分の1経っても新しく記事が書けてないので凹んでます。
本題。
php案件と言いつつ今時は画面側の処理書く時に
javascriptはセットなわけで。
大抵は使用するwebアプリケーションフレームワークに
基本的な処理は入ってるのですが
THE・Excelなセル結合を駆使したネ申フォーマットの前には無力です。
どなたかクライアントに1レコード行あたりにtrタグ何個も使って
colspanやrowspanをフルに使う寄木細工フォーマットは
作る側も保守・運用する側も地獄ってことを
伝えていただけないでしょうか（虚空に消えていく愚痴）
本記事はそういうネ申フォーマットに行挿入処理を実装する時の方法です。
1. コピー用のレコード行を別に用意する
trタグ１つ、つまり1行で済むなら
元からあるレコード行をcloneNode(true)して
inputタグの中身をクリアしたら一丁あがりだと思います。
もしくはタグ生成処理をして追加するかかと。
が、複数行にまたがる場合、trタグ毎に処理実装が必要になり、
html部分の変更が生じるとtrタグ毎の処理を1行ずつ確認して
修正になります。
（colspanやrowspanを使っているのでどのtrタグにあるかわかりにくい）
そこでcloneNode(true)用のレコード行をdisplay:noneで別に用意します。
初めから空なのでクリア処理を考える必要がなくて楽です。
phpでsmartyを利用しているならレコード行部分のhtmlを1つのtplファイルに書いて
表示する部分とdisplay: noneのtableタグの中身に出力するようにすると
html部分の変更が生じてもレコード行部分のhtmlを記述したtplファイルの中を修正するだけで終わるのでメンテしやすいです。
<table id="table_copy" style="display: none;" >
<tr>レコード行1/2</tr>
<tr>レコード行2/2</tr>
</table>
2. javascriptで1をコピーする行挿入処理を実装する
大体こんな感じの処理になると思います。
function row_insert(行挿入ボタンの要素) {
//table要素が取れるまでparentNodeを繋げる
var table_tag = 行挿入ボタンの要素.parentNode.parentNode;
//tr要素が取れるまでparentNodeを繋げる
var tr_tag = 行挿入ボタンの要素.parentNode;
//コピー用のtable要素取得
var copy_table_tag = document.getElementById("copy_table");
//挿入行のインデックスを取得
var index = tr_tag.rowIndex;
//挿入行にtrタグを差し込む(1)
table_tag.insertRow(index);
//コピー用table要素から1行目をコピー(2)
var copy_tr_tag1 = copy_table_tag.rows[0].cloneNode(true);
//差し込んだtrタグに中身を格納する(3)
table_tag.rows[index].innerHTML = copy_tr_tag.innerHTML;
//2行目以降はindex+1,index+2・・・,copy_table_tag.rows[1],[2],・・・で処理を調整する
}
後は必要に応じて処理を修正していけばいいかと。
3. まとめ
取りあえずこの記事書いてみましたが
この実装でもメンテ大変そうな気がするので
可能なら
レコード行をtrタグ1個の中に納めませんか？
せめてrowspan使うのやめませんか？
って確認or提案した方が幸せになれる気がします。
願わくばこの記事読んでる人がこういう意見・提案を
聞いてもらえるお仕事でありますように。
Happy Javascript life!
emacsのdefmacroメモ。
( ´_ゝ｀)ノシ
yoshitiaです。
evil-modeのdefmacro読もうとした時に？となった点をメモ。
defmacroの中に入ってる良くわからないもの
(declare (indent defun))
というコードがあって
macroexpandでマクロを展開しても
出力結果がインデント調整されてるわけでもないので
かなり謎でした。
init.el読書会で解決
丁度2016/12/24のinit.el読書会で出てきたinit.elで
defmacroが出てきたので@poginさんに聞いたら即答でした。
(declare (indent defun))で調整されるもの
defmacroでマクロを定義した後、
マクロを書くタイミングで効果が出ます。
式の途中で改行を行った時のインデント方式の指定を
行っているようです。
@poginさんに出してもらった例
;; (declare (indent defun))無し (defmacro after1 (mode &rest body) "`eval-after-load' MODE evaluate BODY." `(eval-after-load ,mode '(progn ,@body))) ;; (declare (indent defun))あり (defmacro after2 (mode &rest body) "`eval-after-load' MODE evaluate BODY." (declare (indent defun)) `(eval-after-load ,mode '(progn ,@body)))
上記マクロ2つを評価した後に書いたコード
;; (declare (indent defun)) なし (after1 'dired (define-key dired-mode-map (kbd "M-p") 'dired-back-to-top) (define-key dired-mode-map (kbd "M-n") 'dired-jump-to-bottom) (define-key dired-mode-map (kbd "C-a") 'dired-back-to-start-of-files)) ;; (declare (indent defun))あり (after2 'dired (define-key dired-mode-map (kbd "M-p") 'dired-back-to-top) (define-key dired-mode-map (kbd "M-n") 'dired-jump-to-bottom) (define-key dired-mode-map (kbd "C-a") 'dired-back-to-start-of-files))
それぞれ2行目以降のインデントはemacsが自動で調整したものです。
indent後ろにdefunや1やら値を指定するとそれに応じて
マクロのインデントの方式が決まるようです。
evil-modeのelispをちょっと覗いてみる
本記事は Emacs Advent Calendar 2016 の5日目の記事になります。
( ´_ゝ｀)ノシ
VimConf2016が終わったと思ったらこんな季節に。
ネタは何かと問われれば
Emacs with evil-mode が主戦力の Vimmer なので
evil-mode の elisp を見てみる、そういう事になった。
Spacemacsのユーザーが増えているようですが
各種elispのviキーバインド適応設定+独自設定ファイルまで
詰め込まれているのは重たすぎると思うので
当分evil-modeのままで行きます。
内容は emacs 何それ美味しいの？人向けのレベルです。
ただし、何がしかのプログラミング言語が読めないとツライです。
evil.info
ここにevilのインストール方法とか書いてある。
evil.el
ここが.emacs(init.el)で
(add-to-list 'load-path "~/.emacs.d/evil") (require 'evil)
と書いて起動した時に読み込まれる部分。
evil.elのコード
;;; Code: (require 'evil-vars) (require 'evil-common) (require 'evil-core) (require 'evil-states) (require 'evil-repeat) (require 'evil-macros) (require 'evil-search) (require 'evil-ex) (require 'evil-digraphs) (require 'evil-types) (require 'evil-commands) (require 'evil-maps) (require 'evil-integration) (run-hooks 'evil-after-load-hook) ;;;###autoload (define-globalized-minor-mode evil-mode evil-local-mode evil-initialize) (provide 'evil) ;;; evil.el ends here
コードの説明。
require 'xxx
;はコメントアウト。
(require 'evil-vars) で
(provide 'evil-vars) と記述されている
evil-vars.elを読み込む。
*-hook
(run-hooks 'evil-after-load-hook) で
一通りのevil-modeを構成するelispをロード後に
hookを読み込みます。
EmacsではEmacs上のイベント発生時に
ユーザーが読み込ませたい処理を仕込んでおく変数として
*-hookが用意されています。
evil-after-load-hook については
evil-vars.el 内で定義されています。
つまり、自分でelispでmode作る時は必要に応じて定義しておくものになります。
(define-globalized-minor-mode evil-mode evil-local-mode evil-initialize)
モード定義
define-globalized-minor-mode で
evil-mode、evil-local-mode、evil-initialize-mode を
どのバッファでも利用できるマイナーモードとして扱うように設定します。
(evil-mode は viキーバインドを実現する elisp なのでこの扱いが丁度いい)
バッファを開く際のメジャーモードで evil-mode が不都合な場合は
そのメジャーモードの hook で evil-mode をオフにすることができます。
(メジャーモード・マイナーモード・バッファは
Emacs独自の定義があるので興味があればググッてください。)
雑に言うと開くタブ毎に evil-mode のオン・オフ切り替えの設定・操作が可能です。
vimconf2016に参加した話
( ´_ゝ｀)ノシ
yoshitiaです。
今年は開始時刻に間に合いました。
2年連続で開始時刻後に受付してたもので・・・
会場は 株式会社ミクシィ 様です。
mixi.co.jp
yoshitiaは vimconf2014 からの参加ですが
3年連続同じ会場となりました。
mixiさんマジ男前です。
発表のスライドと動画が公式ページにアップされるらしいので
正確な内容はそちらにおまかせして
ざっくりとした感想を。
感想
Vim7 から Vim8 へ
今回の発表で取り上げられていたポイントで大きなものは
メジャーバージョンアップで Vim7 → Vim8 になった話でした。
エンドユーザー側には直接影響のある機能追加というのはありませんが
Vim script プラグインを作成する上での追加はたくさんあります。
ざっくり言うと Vim8.0 以前より便利なプラグインが
作れるようになったということです。
.vimrc の見直しついでに新しいプラグインの探し時かもしれません。
Vim との連携で採用されるプログラミング言語
Vim と言えばコマンドラインとの連携ですが、
ここ数年の発表やそれ以外のweb記事などを見ていると
連係するプロダクトのプログラミング言語として
python と golang が選択されていく傾向にあるようです。
特に今回は golang が絡む発表が多く、
参加者の中から ここは Vim のカンファレンス会場だよね？と言う声が
実際出ていた程です。
今後、 python と golang が Vim を便利に使う上で欠かせないものと
してますます不動の地位を築くのではないか、と感じさせる Vimconf でした。
python
python は C で作るほどでもないコマンドや、
既存の *NIX コマンドに使い勝手の良い機能をちょっと足す目的、
または新しくコマンドを作る前の試作に使われるなど
Linuxに標準で入っていないと困るレベルで使われています。
golang
golang は フォーマッタ や linter 等、言語レベルで開発を助けるライブラリが
かなり充実しているため開発者からすごく評判の良い言語です。
私見ですが、個人別で宗教論争になりやすいコードの細かい文法を
できるだけ取り除こうという方針で設計されている言語のようです。
golang はコードをコンパイルして
実行ファイルを作成・使用するのが主な利用方法ですが
言語レベルで複数の OS 向けに対応した実行ファイルを作成できる
クロスコンパイルをサポートしています。
C だと複数の OS に対応する場合、OS に応じたコードを
追加する必要があります。
Vimは対応している OS が多いためそれに対応するコードも沢山あります。
完全に各 OS 対応のコードが不要かどうかまではyoshitiaの勉強不足で
わからないですが、同じものをCで書くよりはかなり楽になるようです。
Vim 以外のテキストエディタ
今回の発表者の口からでてきたテキストエディタで
yoshitiaが気になっているものは
Visual Studio Code と Atom になります。
2つのテキストエディタの共通点としては
html・css・Javascript等で作られているElectronベースであることです。
Visual Studio Code
Microsoft が提供している製品になります。
2014年以降、Windows OS の枠を超えた製品を積極的に出すようになってからの
今時のテキストエディタです。
Microsoft が提供しているだけあってMS系の言語サポート、Visual Studioのような
インテリセンス（入力補完）も可能です。
更に今時の有名どころのプログラミング言語に関するサポート機能があるようです。
（詳細は Visual Studio Code の公式ページにあります。）
yoshitiaとしては「 Microsoft が提供している」点に注目しています。
セキュリティ上の理由で開発や業務の効率化のためのツールの導入を
拒んで非効率な作業環境で従業員に生産性を求めざるを得ない企業に
新しい選択肢を提供できるツールになるんではないかと期待しています。
Atom
github 製のテキストエディタです。
Electron ベースで作成されているのですが、
ファイルのエクスプローラ、ウィンドウ分割、
コマンドパレット、ウィンドウ内での端末起動など
今まで試してきたテキストエディタの中で
扱いやすさは別格だと感じます。
キーバインドは今回の発表者の1人、 @t9md さんのvim-mode-plus等に
お世話になっています。
yoshitiaは今回の発表者の1人、 @kaoriya さんの言う所のスパルタンVimmer、
極力デフォルトのキーバインドを崩さずに利用することを選択しています。
なので他のエディタやIDEのviエミュレートプラグインについては
「軽いテキスト編集程度の作業に支障なければそれでよし、
本腰入れたテキスト編集作業はVimでやればいいじゃない。」
と考えています。
その点、 @t9md さんのプラグインは素晴らしいです。
（Vimにはない機能をAtomの特性を利用して追加してる貪欲さには震えました。）
後、直接的なポイントではありませんが
html・css・javascriptで作られている所を注目しています。
開発者の確保がソフトウェア存続の必須要素である以上
利用している人口が多い技術を採用するのはアリではないかと。
余談: Vimmer に関して
Vim を使う人に出会った事が無い方は意外かもしれませんが
Vimmer はVim 以外をテキストエディタとして認めないとか
他人に Vim を押し売りで使い方を教えることはありません。
yoshitia自身、emacs も サクラエディタ も使います。
最近 秀丸エディタ も使ったりするようになりました。
Vim の機能やプラグイン自体、他のエディタやIDEを参考にしたものが
あるのも Vimmer が Vim に限らず良いエディタを探し求めているだけなのです。
Vim の使い方を
メモ帳レベルの起動・入力・保存・終了
以上に教えようとする場合、
自分から Vim の help を調べたり、
とにかく実際に操作して確かめる、
それを自主的にやる人でないとどんなに優秀な Vimmer でも教えるのは困難です。
もし強引にでも教えられる方法があるならすごく聞いてみたいです。
(他のものでも同じだと思いますが)
その他
最後のLT発表者、 @thinca さんの発表内で
Vimプラグインで他のプラグインや組み込み機能に重複しやすい
コマンド名や関数名・変数の名付け方について
「名前空間を汚すな！それはお前だけの物じゃない！」
は当日の会場に居る全員の心に響いたのではないかと
yoshitiaは思っています。
懇親会
大体 @kamichidu さんと
フロントエンドでhtml・cssメイン、補助にJavascriptを書いてるという方に
サーバがどうのと話をしていた。
あいかわらず @kamichidu さんすごすぎる。
yoshitia自身は人に話できるような実務経験があまりないので
内心「人に偉そうに話できる身分ではないんだけど」と
思いながら話をしましたが、なんらかの収穫がその方にあればいいなぁ。
（その人のtwitterアカウント聞いておけば良かったか・・・）
首都圏で開催されているJavascriptのイベントは人気過ぎて
なかなか参加定員の枠に入れない、と話されていたのは印象に残っています。
@deris0126 さんがかなり酒に酔っていたせいか
VR彼女をプレイしたいと思わないのおかしいでしょ！？と、
曇りの一点も無い本気で発言してたのすごかった。
@kaoriya さんが懇親会中で全力で Vim をdisったらしいと聞いた。
Vim の良い点・悪い点を熟知した上でのそれは
簡単には聞けない話なのですごく聞きたかった。
Vimconf X次会
レアモンスターの @supermomonga さんが Vimconf に来たので
総勢11名でカラオケボックスに。
そしておもむろにノートPCをセッティングし、
vimrc読書会 や各自のプラグイン開発、
rubyの指導をする勢、普通にカラオケする勢と混沌とする室内。
@thinca さん、 vimrc読書会 しながらカラオケを敢行、
それをスマホで撮影されてた。
yoshitiaは
時代とかジャンルに一貫性が無さすぎる選曲をしてたので
迷惑掛けたかもしれない。
正直すまんかった。
最後に
毎年思ってはいることですが、
ドキュメントの翻訳・Vim本体のパッチ・Vimプラグインの
いずれかで Vimコミュニティに貢献できるレベルに到達したいなぁ。
この記事を読んで頂いた Vimconf2016 の参加者の皆様へ。
今回の参加記事をまだwebにupしてないなら
「Vimconf2016に参加した。楽しかった。」だけでもいいので
記事作成をしていただけると嬉しいです。
（詳細な感想は暇な時に更新したらいいんです。）
参加者の多くが参加記事を書いていただくことで
Vimconf 2017にスポンサーが付くかもしれません。
スポンサーが付く、と言う事には本音を言うと
どうでも良いのですが
それにより、
Vim の開発者でありメンテナの Bram 氏や
国内外の著名な技術者を招待可能な体制が出来る、
これにはすごく魅力を感じます。
たった1行でOSSのコミュニティに貢献できるチャンスって中々ないですよ！
では、今後のVimconfの発展を願いつつ記事を〆ます。
Happy Vim Life!
windowsのkaoriya版gvimでvimtutorを開く話
2016/12/14追記
kaoriya版gvimでvimtutorを開くには
:Tutorialコマンドでokらしいですorz
crazymasterさん指摘ありがとうございますm(_ _)m
github.com
( ´_ゝ｀)ノシ
yoshitiaです。
他人にはVim歴の方が長いのにEmacs使いと認識されてたり、
やたらExcelVBAに詳しそうと認識されてるようです。
（当人はえっそうなん？状態）
BASIC派生言語が習得しやすい言語で、
Excelが基本機能+VBA+ユーザーフォームをフルに使えば、
下手な業務システムを絶滅させられる、
そのくらいのポテンシャルを持ってるのは理解しています。
が、「VBA専門の人」と認識されると
ツール制限のキツイ環境で
VimもEmacsも使えない確率が高い現場になるので
すっごく避けたいです。
・・・本題。
windowsのkaoriya版gvimでvimtutorを開く
1. <Esc>:e $VIMRUNTIME\tutor\vimtutor.ja.utf-8と入力してEnter。
上手く表示されない場合は
<Esc>:e $VIMRUNTIME\tutor\vimtutor.ja.sjisを試す。
2. <Esc>:w! TUTOCOPY
3. 一旦gvim閉じた後再開する場合は<Esc>:vi TUTOCOPY
上記手順が良くわからない人向け
下記ページを保存してvimtutor.batファイルをデスクトップに作ってクリックする。
https://raw.githubusercontent.com/airblade/vim/master/vimtutor.bat
カービングとモデリングとプログラミング
( ´_ゝ｀)ノシ
yoshitiaです。
特に何という事はなく気になった単語をメモる。
コンピュータ・ソフトウェア関連は建築や芸術分野から
用語が輸入されたりするらしい。
こういうのは語源から調べるとイメージの助けになる。
モデリング、の単語が気になって調べていたら
彫刻の分野では、作品を制作する技法に
カービング と モデリング というものがあると。
- カービング（Carving）
- 木や石、金属等の硬い素材を削りだすことで
彫刻を作成する技法
- モデリング（Modeling）
- 粘土等の軟らかい素材を盛ったり削ったり整えたりして
彫刻を作成する技法
カービングはイメージ通り、削り出しの一発勝負で
やり直しが難しいみたい。
仏師さんだと「完成像をはっきりさせたら、それを素材から取り出す」
と表現するみたい。
プロジェクトで言ったら、
過去に実績のあるシステムで
要件定義が過不足なく揃ってて
各工程の資料も揃ってる、
みたいなものだろうなぁ。
モデリングは、素材が柔らかい分後から変更が効きやすい。
変更が効きやすすぎて当初の完成像から外れてしまう危険性もあるという。
プロジェクトで言ったら、
過去の実績があまりなくて
要件定義も出揃って無く、
ビジネスの要求によっては
大きい変更の可能性があって
工数の見通しも中々立たない、
みたいなものだろうなぁ。
まとめ
とりあえず、カービングって単語をあまり聞かない理由は判った気がした。
VBA で small is beautiful. する話【修正版】
※前の記事はコードの色表示が上手くいかなかったので削除しました。
( ´_ゝ｀)ノシ
yoshitiaです。
前の現場ではbashとSQLでしたが、
新しい現場では VBA 、 VBscript 、コマンドプロンプトとMSづくしです。
そんな現場ですが Unix哲学が役にたたないわけではないです。
今回の記事では Unix哲学の1番目に出てくる
small is beautiful. （小さいことはいいことだ）
コードの単位を細かく細かくすることで
扱いやすいプログラムにする考え方です。
これをVBAで実践する例を書いていこうと思います。
https://www.amazon.co.jp/dp/4274064069/ref=cm_sw_r_tw_dp_x_M983xbVA8A8SXwww.amazon.co.jp
環境
Excel2007以降のxlsmファイルに標準モジュール作成
標準モジュール上でコードを書く。
small is beautiful. 実践前のコード
Option Explicit Sub ワークシートチェック() Dim ワークシート As Worksheet Dim セルからの取得値 As String Set ワークシート = ThisWorkbook.Worksheets("sheet1") セルからの取得値 = ワークシート.Range("A1").Value If セルからの取得値 = "" Then MsgBox "A1セルが空です" Else MsgBox "A1セル空欄チェックOK" End If End Sub
sheet1 の A1セルの値が空かどうかチェックする簡単なコードです。
例としてはまだ処理が少ないので読めますが
後から読む人にとっては何の処理をしているか
すぐにはつかみにくいです。
これを書き換えてみます。
small is beautiful. 実践後のコード
Option Explicit Sub ワークシートチェック() Dim ワークシート As Worksheet Dim セルからの取得値1 As String Set ワークシート = ThisWorkbook.Worksheets("sheet1") セルからの取得値1 = ワークシート.Range("A1").Value MsgBox セルチェック1("A1", セルからの取得値1) End Sub Function セルチェック1(セルの場所 As String, セルからの取得値 As String) As String セルチェック = 空欄チェック(セルの場所, セルからの取得値) End Function Function 空欄チェック(セルの場所 As String, セルからの取得値 As String) As String If セルからの取得値 = "" Then 空欄チェック = セルの場所 & " が空です" Exit Function End If 空欄チェック = セルの場所 & " 空欄チェックOK" End Function
実践後のコードです。
人によっては「余計に複雑になった」と思う人もいるかもしれません。
ここで、メインの ワークシートチェック() だけを見てみます。
Option Explicit Sub ワークシートチェック() Dim ワークシート As Worksheet Dim セルからの取得値1 As String Set ワークシート = ThisWorkbook.Worksheets("sheet1") セルからの取得値1 = ワークシート.Range("A1").Value MsgBox セルチェック1("A1", セルからの取得値1) End Sub
ここからさらに見る範囲を絞ります。
Set ワークシート = ThisWorkbook.Worksheets("sheet1") セルからの取得値1 = ワークシート.Range("A1").Value MsgBox セルチェック1("A1", セルからの取得値1)
Excelを扱ったことのある人なら
「sheet1 の A1セルに入力されている値をチェックしている」
となんとなくは読み取れると思います。
では、最初のコードではどうでしょう。
Option Explicit Sub ワークシートチェック() Dim ワークシート As Worksheet Dim セルからの取得値 As String Set ワークシート = ThisWorkbook.Worksheets("sheet1") セルからの取得値 = ワークシート.Range("A1").Value If セルからの取得値 = "" Then MsgBox "A1セルが空です" Else MsgBox "A1セル空欄チェックOK" End If End Sub
このコードだと If文以降を全部読んで確認しないと
A1セルをチェックしている処理だと把握できません。
コードを小さくする時の考え方
コードの何を小さくしているかの話です。
具体的には処理の内容を分割しています。
コード全体の処理内容は
「sheet1 の A1セルの値が空かどうかチェックする」です。
これを次のような単位に分けます。
- 「セルの値をチェック」
- 「セルが空かどうかチェック」
「セルが空かどうかチェック」の部分は
「セルの値をチェック」の中に入っています。
利用する人は、「セルの値をチェック」に
対象のセルの値をセットするだけで使えます。
利点その1. 再利用しやすい
コピペで使いやすいです。
例えば、追加で「A2セルもA1セルと同じチェックをしたい」場合、
変数宣言に```Dim セルからの取得値2 As String```を追加
値取得に```セルからの取得値2 = ワークシート.Range("A2").Value```を追加
ここまでは実践前・実践後両方同じですが
処理を追加する場合、
small is beautiful. 実践前
If セルからの取得値2 = "" Then MsgBox "A2セルが空です" Else MsgBox "A2セル空欄チェックOK" End If
small is beautiful. 実践後
MsgBox セルチェック1("A2", セルからの取得値2)
追加する量が変わってきます。
チェックするセルの数が増えるほど差が出ます。
利点その2. 機能追加しやすい
ただ、これだけでは
Function セルチェック1 と Function 空欄チェック
この2つに分けた利点が分かりにくいと思います。
私も今までの説明だけなら
Function セルチェック1 に Function 空欄チェック のコードも
まとめればいいと思います。
しかし、このように分けているのも理由があります。
例えば、「A1セルの値が"1"かどうかのチェックも追加したい」
となった場合、Function セルチェック1にまとめてしまっていると
融通が効きません。
Function セルチェック1 と Function 空欄チェック のように分けていると
A1セルの処理
- 「セルの値をチェック」
- 「セルが空かどうかチェック」
- 「セルの値が1かどうかチェック」
A2セルの処理
- 「セルの値をチェック」
- 「セルが空かどうかチェック」
のように対象のセルごとにチェックの種類を
楽々追加/削除ができるようになります。
実際のコードは以下のとおりになります。
Option Explicit Sub ワークシートチェック() Dim ワークシート As Worksheet Dim セルからの取得値1 As String Dim セルからの取得値2 As String Set ワークシート = ThisWorkbook.Worksheets("sheet1") セルからの取得値1 = ワークシート.Range("A1").Value MsgBox セルチェック1("A1", セルからの取得値1) セルからの取得値2 = ワークシート.Range("A2").Value MsgBox セルチェック2("A2", セルからの取得値1) End Sub Function セルチェック1(セルの場所 As String, セルからの取得値 As String) As String Dim チェックする値 As String チェックする値 = "1" セルチェック = 空欄チェック(セルの場所, セルからの取得値) セルチェック = セルチェック & vbCrLf & 値チェック(セルの場所, セルからの取得値, チェックする値) End Function Function セルチェック2(セルの場所 As String, セルからの取得値 As String) As String セルチェック = 空欄チェック(セルの場所, セルからの取得値) End Function Function 空欄チェック(セルの場所 As String, セルからの取得値 As String) As String If セルからの取得値 = "" Then 空欄チェック = セルの場所 & " が空です。" Exit Function End If 空欄チェック = セルの場所 & " 空欄チェックOK。" End Function Function 値チェック(セルの場所 As String, セルからの取得値 As String, チェックする値 As String) As String If セルからの取得値 <> "1" Then 空欄チェック = セルの場所 & "の値が " & チェックする値 " ではありません。" Exit Function End If 値チェック = "チェックOK。 " & セルの場所 & " の値は " & セルからの取得値 & " です。" End Function
コードの量は増えましたが
ワークシートチェック()の部分だけを見てみると
Option Explicit Sub ワークシートチェック() Dim ワークシート As Worksheet Dim セルからの取得値1 As String Dim セルからの取得値2 As String Set ワークシート = ThisWorkbook.Worksheets("sheet1") セルからの取得値1 = ワークシート.Range("A1").Value MsgBox セルチェック1("A1", セルからの取得値1) セルからの取得値2 = ワークシート.Range("A2").Value MsgBox セルチェック2("A2", セルからの取得値1) End Sub
追加前と比較して
Dim セルからの取得値2 As String
セルからの取得値2 = ワークシート.Range("A2").Value
MsgBox セルチェック2("A2", セルからの取得値1)
の追加だけで済んでいます。
初めてこのコードを見る人でも
「sheet1 の A1セル と A2セル のチェック処理」
と概要を把握しやすいです。
まとめ
最後に、Unix哲学を元にコードを書いている時の私のイメージは
ゲームで1000回攻撃しないと倒せない相手を、
必殺技などを使わずに
愚直に連続攻撃を、隙間なく、1000回叩きこんで倒すイメージです。
（実際のゲームでは1000回は不要でしょうが）
https://www.amazon.co.jp/dp/4274064069/ref=cm_sw_r_tw_dp_x_M983xbVA8A8SXwww.amazon.co.jp
『UNIXという考え方』でもゴジラを題材に
Unix哲学を元に難問に立ち向かう開発者のイメージが語られています。
例として示したコードはまだまだ使い勝手が良くないです。
もっと良いコードの書き方はあるはずです。探しましょう。
Unix哲学についてはsmall is beautiful. 以外にもありますので
webの記事や書籍『UNIXという考え方』で見ると良いと思います。
