From aee1b4b0947d9ce3f6f24b672d51190862e19c47 Mon Sep 17 00:00:00 2001 From: jeff Date: Thu, 18 Jun 2020 08:20:07 -0700 Subject: [PATCH 01/12] Add docker commands for building and running development. --- README.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/README.md b/README.md index 4466ca6..9c1d197 100644 --- a/README.md +++ b/README.md @@ -7,6 +7,12 @@ Built using [Hugo](https://gohugo.io/getting-started/installing/) hugo server ``` +Development can also be run using Docker: +```shell script +docker build --no-cache -f Dockerfile.dev -t website-fe . && \ +docker run -it -p 1313:1313 --mount source=$(pwd),target=/src,type=bind --rm website-fe +``` + ## Production To build the production site, run the following command: ``` -- 2.45.2 From 5705040953c1bc52b77a47c8833804b0f02d2131 Mon Sep 17 00:00:00 2001 From: jeff Date: Tue, 14 Jul 2020 21:46:03 -0700 Subject: [PATCH 02/12] checking in --- content/blog/boolean_names.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 content/blog/boolean_names.md diff --git a/content/blog/boolean_names.md b/content/blog/boolean_names.md new file mode 100644 index 0000000..f587e65 --- /dev/null +++ b/content/blog/boolean_names.md @@ -0,0 +1,30 @@ +--- +img: /img/settings.png +title: "Boolean Variable Names" +author: Jeff Russo +pdate: FILL_IN_DATE +desc: Choosing a good boolean variable name +--- + +Choosing good names for variable is important. They are a form of documentation and can remove [complexity](http://localhost:1313/blog/complexity/) from code. Using a bad name for a variable leads to confusion, bugs, and wasted engineer time. In this blog post I will discuss what makes a variable name good or bad, for [booleans](https://en.wikipedia.org/wiki/Boolean_data_type) in particular. + +## Purpose +A boolean's purpose is to toggle between true and false. Therefore, the name should represent something that is true or false. + +## Good Boolean Names + + +## Bad Boolean Names + +Variable names for booleans: avoid names that are already a negation (notReady, headless). + +find examples in OSS (Gitea notify) + + +Read PoP and PoSD for bool blog post +Use an unambiguously negatable name. No context should be needed for understanding. Ex: “FlexibleName” +Going between configs is problematic. Ex: confA.UseProd = !confB.NoProd +Should be in the affirmative (useProd, not noProd) + + +answerable with yes or no (true or false) -- 2.45.2 From 971a09373373cee00ba3d13c7f2c8596acf25f0f Mon Sep 17 00:00:00 2001 From: jeff Date: Sat, 18 Jul 2020 11:41:55 -0700 Subject: [PATCH 03/12] checking in --- content/blog/boolean_names.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/content/blog/boolean_names.md b/content/blog/boolean_names.md index f587e65..170baf5 100644 --- a/content/blog/boolean_names.md +++ b/content/blog/boolean_names.md @@ -9,7 +9,7 @@ desc: Choosing a good boolean variable name Choosing good names for variable is important. They are a form of documentation and can remove [complexity](http://localhost:1313/blog/complexity/) from code. Using a bad name for a variable leads to confusion, bugs, and wasted engineer time. In this blog post I will discuss what makes a variable name good or bad, for [booleans](https://en.wikipedia.org/wiki/Boolean_data_type) in particular. ## Purpose -A boolean's purpose is to toggle between true and false. Therefore, the name should represent something that is true or false. +A boolean's purpose is to toggle between true and false. Therefore, the name should represent something that can be true or false. ## Good Boolean Names @@ -20,6 +20,8 @@ Variable names for booleans: avoid names that are already a negation (notReady, find examples in OSS (Gitea notify) +The book, _The Elements of Style_1, is a concise guide to writing. Some rules can be used as a guide for writing code as well. For example, rule 11, "Put statements in positive form," can be applied to naming boolean variables. Keep boolean names in the positive as well, with one additional requirement: do not use the positive form of a negative statement. `enabled` is in the positive form and a positive statement. `disabled` is in the positive form, but is a negative statement. `notEnabled` is both in the negative form and a negative statement. In writing, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for names is because boolean variables' negations have meaning as well; in writing "not disabled" is a double negative and is discouraged. In code, `!disabled`, is also a double negative. + Read PoP and PoSD for bool blog post Use an unambiguously negatable name. No context should be needed for understanding. Ex: “FlexibleName” @@ -28,3 +30,5 @@ Should be in the affirmative (useProd, not noProd) answerable with yes or no (true or false) + +1 https://tinyurl.com/y3uxhzxc -- 2.45.2 From b0c63765d1bfed841c72c6008c579cd30061440d Mon Sep 17 00:00:00 2001 From: jeff Date: Sat, 18 Jul 2020 11:57:24 -0700 Subject: [PATCH 04/12] checking in --- content/blog/boolean_names.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/boolean_names.md b/content/blog/boolean_names.md index 170baf5..7de76e7 100644 --- a/content/blog/boolean_names.md +++ b/content/blog/boolean_names.md @@ -20,7 +20,7 @@ Variable names for booleans: avoid names that are already a negation (notReady, find examples in OSS (Gitea notify) -The book, _The Elements of Style_1, is a concise guide to writing. Some rules can be used as a guide for writing code as well. For example, rule 11, "Put statements in positive form," can be applied to naming boolean variables. Keep boolean names in the positive as well, with one additional requirement: do not use the positive form of a negative statement. `enabled` is in the positive form and a positive statement. `disabled` is in the positive form, but is a negative statement. `notEnabled` is both in the negative form and a negative statement. In writing, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for names is because boolean variables' negations have meaning as well; in writing "not disabled" is a double negative and is discouraged. In code, `!disabled`, is also a double negative. +The book, _The Elements of Style_1, is a concise guide to writing. Some rules can be used as a guide for writing code as well. For example, rule 11, "Put statements in positive form," can be applied to naming boolean variables. Keep boolean names in the positive as well, with one additional requirement: do not use the positive form of a negative statement. `enabled` is in the positive form and a positive statement. `disabled` is in the positive form, but is a negative statement. `notEnabled` is both in the negative form and a negative statement. In writing, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for names is because boolean variables' negations have meaning as well; in writing "not disabled" is a double negative and is discouraged. In code, `!disabled`, is also a double negative, and should be avoided. Read PoP and PoSD for bool blog post -- 2.45.2 From 07740192a0b88ae99463a2b599a5103a2f6e20d6 Mon Sep 17 00:00:00 2001 From: jeff Date: Sun, 26 Jul 2020 21:51:16 -0700 Subject: [PATCH 05/12] checking in --- content/blog/boolean_names.md | 33 +++++++++++++-------------- static/img/yinyang-simplesystems.png | Bin 0 -> 11035 bytes 2 files changed, 16 insertions(+), 17 deletions(-) create mode 100644 static/img/yinyang-simplesystems.png diff --git a/content/blog/boolean_names.md b/content/blog/boolean_names.md index 7de76e7..2005f58 100644 --- a/content/blog/boolean_names.md +++ b/content/blog/boolean_names.md @@ -1,34 +1,33 @@ --- -img: /img/settings.png +img: /img/yinyang-simplesystems.png title: "Boolean Variable Names" author: Jeff Russo -pdate: FILL_IN_DATE +pdate: June 50, 2020 desc: Choosing a good boolean variable name --- -Choosing good names for variable is important. They are a form of documentation and can remove [complexity](http://localhost:1313/blog/complexity/) from code. Using a bad name for a variable leads to confusion, bugs, and wasted engineer time. In this blog post I will discuss what makes a variable name good or bad, for [booleans](https://en.wikipedia.org/wiki/Boolean_data_type) in particular. - -## Purpose -A boolean's purpose is to toggle between true and false. Therefore, the name should represent something that can be true or false. +Choosing good names for variables is important. They are a form of documentation and can remove [complexity](http://localhost:1313/blog/complexity/) from code. Using a bad name for a variable leads to confusion, bugs, and wasted engineer time. In this blog post I will discuss what makes a [boolean](https://en.wikipedia.org/wiki/Boolean_data_type) variable name good or bad. ## Good Boolean Names +Boolean names should be negatable, and in the positive form. These names should be clear and concise just as all variable names should be. As the scope of the variable increases, it's level of description should increase as well. +The book, _The Elements of Style_ 1, is a concise guide to writing English. Some rules can be used as a guide for writing code as well. For example, rule 11, "Put statements in positive form," can be applied to naming boolean variables. In code, there is one additional requirement: the statement must be positive as well. 'enabled' is in the positive form and a positive statement. 'disabled' is in the positive form, but is a negative statement. 'notEnabled' is both in the negative form and a negative statement. + +In English, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for boolean names is because boolean variables' negations have meaning as well; in writing "not disabled" is a double negative and is discouraged. In code, '!disabled', is also a double negative, and should be avoided. + +A boolean name should give the reader more clarity as it's scope expands. In [Go](https://play.golang.org/p/i1W05p5EpAN), a boolean variable that exists for the scope of an if statement may have a short name ('ok'). If this variable was in scope throughout the function, it would become meaningless. ## Bad Boolean Names +As with many things in software engineering, it is easier to find mistakes than to do something correctly the first time. Here are some naming conventions to avoid: +1. Names that are already a negation. 'notReady' and 'notProd' may make sense in one use case, but becomes confusing in a larger context. This can lead to code such as, `confA.useUAT = !confB.notProd`. This is both hard to read and ambiguous (what if there is a third environment). -Variable names for booleans: avoid names that are already a negation (notReady, headless). +2. Names that are not negatable. A name such as, 'sheets', has ambiguous meaning. It probably has something to do with a spreadsheet, but it is the writer's responsibility to prevent the reader from needing to do an investigation. -find examples in OSS (Gitea notify) +3. Names that are in negative form. These usually appear when the typical behavior is the negative form. For example, 'disabled'. Keep all the names in positive form to avoid a future headache explaining what the billing system does when it's "not disabled". Is it enabled, or is it just not disabled? -The book, _The Elements of Style_1, is a concise guide to writing. Some rules can be used as a guide for writing code as well. For example, rule 11, "Put statements in positive form," can be applied to naming boolean variables. Keep boolean names in the positive as well, with one additional requirement: do not use the positive form of a negative statement. `enabled` is in the positive form and a positive statement. `disabled` is in the positive form, but is a negative statement. `notEnabled` is both in the negative form and a negative statement. In writing, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for names is because boolean variables' negations have meaning as well; in writing "not disabled" is a double negative and is discouraged. In code, `!disabled`, is also a double negative, and should be avoided. +4. Overly general names. As discussed earlier, this depends on the scope of the name. Avoid using a name such as, 'on'. It leaves questions in the reader's mind such as, "What is on?". The exception to this is typical boolean names used across code bases; Go's 'ok' is an example of this. - -Read PoP and PoSD for bool blog post -Use an unambiguously negatable name. No context should be needed for understanding. Ex: “FlexibleName” -Going between configs is problematic. Ex: confA.UseProd = !confB.NoProd -Should be in the affirmative (useProd, not noProd) - - -answerable with yes or no (true or false) +## Conclusion +This blog post discussed a goal to aim at (good names), and several things to avoid (bad names). Combined, these will hopefully increase the readability of your software! 1 https://tinyurl.com/y3uxhzxc diff --git a/static/img/yinyang-simplesystems.png b/static/img/yinyang-simplesystems.png new file mode 100644 index 0000000000000000000000000000000000000000..7bba262d76d1ee7d6ce7d8bd67535e59aade1cfc GIT binary patch literal 11035 zcmZv?c{o*H^gq7Oom^a8^UM`xEQHMNk%}f6$`Iw2LT06q;T|bzFf>VJxKv1)qBIz8 zG8Pgk8LuIfd7iF&e%_zo_j!KL_xF7EKl|*x*EwgeXRr0zueF|a!^YZ@k4K6J0Km83 zYL6WNn9WBFAYwPW&)G^1n_a2Rp`&{@`&+ke&CbqFPfy#}*i24N9zJ~7+1dH%(W3_r z99URbu(PvsaBy&Sb+xp#93LNdb8|a&>Xe_KpO24ETwL7Mt5>6=qtBf?=kD$v931TF z=@}av8y+5h_Uze!fPk^Fv7n%!(9qDRsHlN~fj@u#{QmvBx3@PWB&4IGpy+^R9sw~nVI?i{rj4lnm2FWeEIUFyu7@ipdc|Z zvBmni>E^znU^{Dj0FQKf0H7wie~e_{E`+tWl_lNvmn=g?G&79|a=NsV1AP7_HM|j5F`c^V&8=MOK zo&SlxGEq~ez4Lz2R4|PPp$f#UN?S0w2`_5l-RYPiTSWKXYQ4M`EwfBa7eygq( znrA*8HT+D3oVk}xC0$-tRDOd{whvZmjct5O{ec-QjjKA{x}IUEO7LE7UJ=}#eqCEZ z$>`q3P3@)E)avaY1k~4|9~am4PF_$J#C?>!aQgARoFGf0uo%HZtnkFMsrEpN)^nAv)0fWOEkAQtsdqA2 znWCWAn>l~S$4+cEAI|gG1)dEK*vpwMe|RCBqS>CaF|_n9<&dR7toGQSwYtxtMlKuO z%HzV>OAm!+@_}Mf?hQV0!{qgi{?Ga`olkN!zjfCt-Kq$=q5b&PQe%XB`bC!J!w1OD zEkTN2C$X?pB6ZXyY(+a}Vdh;*0#`+K2K(ji{uDU@pTW`Dhcev)H@NQV=0ga%P2 znNzC<(#z^s3V+Jy^Iz~7#j6+=l=JJpgedrG+leQ;Ms=L1`5sTrC8PE+h;_kFvKT6G zV=*>X(5m$rf$cdxv2IuPNvmARW98PGdg*gZoNB|Z@*6yA236?t@y~LOzVk|l5x>%p z!xQi3rz4lY+$#mET*PjH#u`oii{|Q&sgc%%VloC}8B>4CSF5{eeL0@ASQpuPc~#lS zCY_MfE<7a`wf|*>YgIyQI4h|WzTF&UV~12aDxM>KzL#}C)se+mu%m>4nJPp|BIE@1P|8zd(=u-yBa z|DX>EYdHn5q!es@sHA-!yMLj)>xf&cq6AQz>1z=Mx-$}Y?w#lGQIxmFS8ddvZm^&K zIxeq+Xs?-KnHpMQOQ$fe&}Xybv!!AN%Y>wRZLupGh0Qfj$(%CugeQ1pAVJyCS@F%r ztXQfC_VH12p7oxa9Gq@;RJ5+uKi8&)O*v(VZJ_o|Ov>Sso(nE?4+p1Sz&3Dm%X4n_ z)5B#iJSGTiZ;)Uf0AW}w!V~`C!dzHcNqOkDG;D2&o7F7CN}_W8VaC!hXP87$j&`)G z_rhroA59H{tbZaS?)o$LR&u%(Vp^B^U{Qif=xPk-0wF21B>VJNdIIQ`8@=fC% z!+DHM1!Q}gP959f*|#I?u|7O!C(TT){0ZRlzo+m?J+c=iOi*^BD^fK5wS#)R7SkYs zV3G+4+ZH=9t_T<_*-`J2R?Tzuq17SP~**MH=KEL9avU?A^SS_W^em zZIaoE&IlLPDl}~Q3`Y&y@Xi)X9D-N^ke3>n+W++L!GD&W{P%N!r4RgZTDf#Y*vd2j z{N+brLO2R?*<^90@} zTut*QuOxnbL^AdS!KkLM9Q2tl$x~=Ir1dY+noq@@Q?CNgYZueY-b+rkmFWY~0s^zs z%xk`|!$0EsSwK zvx~bsO1FW!KK{vgWiXs5fwW;s%n1*`8frJyxS>kmEhcOuBEUJs<=WuF6R^kHW;%X{UP#XL|$EU?uHP4o|}{#kbd@=BJJ z^#0#6UH|hv`Dyz?I^zyiyx=(JCmxwZBkHcUN+a7SI*4TQ6?Vd>klQ!jg0X0Lk%#sh zG|&yR!dDduh`cctUK=CP668f}>Uj`-#@*GYc&$+ZZBJ6tNP#YL$G6RDVr4DE5k72D zAu7bk!Xt#vKboKi?DVn3YK35D0QmCzCM~%@zeB9Ar)MJyFojS-LZpKT7szH)Dc!FuU6D+@-OF)W&vH#Np;tU&X*G@F>Q`<}$i6#QP0oKF^nDI1^ zqk4hAUY+OcT8O&^xGgFN6b)ttIw8v6mt@T>wGMK zrxc=2V!kW;ps!AO{{2-T6s5zDoJk(pG^K*DaO}k7;woz>zr)I_B9dgFDMU@u0~vd2 z+qkY=x;Xz!j8W1Jh(Wut?ComZ?Df$QwZl9{t?jgua7Tl=ko-yBKc2*>^Cy zA1nL&TXmzFz>f|PxH0cnlF6u4?7AEZ1!8ArUt2*tmUH)_;a%bTdl0leH@LRX$X%Q;PB_-0zV9c&+b3B6=K_6`^)B!uOA`!skWdG>gw^pb6-?RO`z)YcTzW=L?zQ6-@ zU@Q1`*n-&?(vW`56M8v#<50_kP;o^<)n~xvBW_IH1O*$F0Kh2bqCnLI`AfN{g^$0d;q_k zlNN;U8WtJhDQa>;P^qPE#mGDX=8xQtLnIme6g+Di_6!fwO#fxYx!dJ_Q3R(NCSBggzwRRX$OLNSMl zL!f{aQ=k;ZFmf?J3gi!s@xf_)ppmZ5To2WiW-JaopQm~t8be{*=<|OBT>BjMLY)_w z^U7bc&7NyvoO%-F z1~ohCE#}iN%O)j$9k{%)7qSTfH{24UPd$=m$U!k)=GW=~xunPx@|e3O2_yonrY}wZ zo4&JX5bvggRgtVxP)EWz*n+7qCIq1~_|OD}sB4fA&Ku0nB}#8nk8fe8GuLrd!Y$N# z8BXsf(04V3H}H7?^Ked$JL58rWF&v6b&yb$0-XB5O|hD%znblwJlF-unz2*~|j5|a~z4J}F704es&V>Vq+!Jl{*#VO%h z8<;UZ4d!dnL}|)NNiN{WhAT>akh%Ry40P&7IRtZB2($tMvJiwFa{xmisfsIg^n++} z3HV}xP>AA(T2nW%1?Jl%8~TVdnn0NGIPp>#R)Nz$-YtNXj^NahFaM!>lHq9tGb_zU z>%+b~!C@ZWpBU4j&K%k%7KVkJ;-H&Epbhla+&n>@-t8`W{q#FLuHegi0!1C3f1pYN zpNyrDOoEoX7Dy=jp#2KXTTn0ETx3Ql-6t?Mx0l=N0a~=N5|ZEYGoY70q+pTq74zkD z#Kut)(hLZl3ItXQVdmttA3w4qnD1SLMz1s3R&XhXG2fWz3-h58#-m++hbJSu&8rZc+Gf5Zp!PN<0#JPS@kaCZsfDQ*N+P2b* zu{H5a?&MO>EqLET-OUK0NRmmSHh`FO`75%tr>OnZW85F=4`}dENm;lhu{Q&W2pTn~-9w{W%-1OIZ!XvD2X8qz~BMw_dS%BDV$!?-Jsq zL%BFE_&7GBY=qi}OV>kc6)7nYa<3VvSIw|PPNjpT_i6_CbRTG#w6e0F&I3~jTA#?+ zlmT!W2zOU5xq~zwnm#@~0225M5iO#j7`7^$8sz^dy&q3Q9`CF$^-3F9*RMK-kq246*eUyV$)X+DATv?oB=w zU3G{m)Ak!2s_Y?wMq??a%hjm>Ono9^=fCBDK3-bI`%LHzLCcL32Q>x8Lx*a*vpG)~ zJ%x1E+BFfDFYknHGbu69*384Qm;2EmQXWJ=dhGV(m`l{!{tKaAlNZK9@ zT)UIE^>f_0Z9WSkodRSe{mSna%E*NddXZETyI@bpX9B~xXtHpnn;r*l>mv;U;?Nmg zDC;S=E2vEeyWqdc|H&|=I_rWXdU>wC6!!Aghrt$Ih}B$mB4dt38YGf!4vt$LHT4H; zZ?y#q-RL6`1QG>&;}49#4rYJa?OAn0 zJE&-q!+j8(zVsevGxYgfSBYL5N#;8d$veQsELyk1{Ak5dcC>Soo6Y*3rDv-5kCf

HAg$y4<2c=OyXA$PZrx1lvws#+@>8p-;SeJLz*^-txXRV-J1`aFiGdp__?zn|kVF zFeeHf)gxB_4$_+(YnG|#$wkyD@oOjq3o)McK!p{PwS?q9rr^zZ=;d66m%=H4ReLSWboo=gU=51Ab*Cp8bd zC}asCgVY4{J;zZA#6H9!#93~MD}eqWZ2ao_m&DvDdv-k+;$Ov*HcwLm>Z^yqh&2qL z6bHnXt-W}kH;9kEBH6k-5s9nm=UKY_fQJmSsp;VF+rGai-iw4lLW@!O2=1l96f;dL$`6|E)$BD@{F(%4v`?RM&od7Z0mrP8Aky99^FdR=cVvf~|A))IR4lvbkL~eaG{kvV;Qn}$M8JgRA{krBgqCO%Et+?E`zUHg-fzWVlO)}>Sk@?jS zvv(;v*WMZ_P+F?bwD>0NpQ0K4%LYeGOunn?4~k~x>3E90-yJMv(f3=gP9j|ds>7jd zb$Egs&V;;(8}QYI^mMM5zQ#-dserhUUA6QHF^a7-9@wV6@M-!?V6AIWXfhn88pZM6 z`-H`+`*=#b*e0wnKNApNeA}@YB0NjaQ{A&X1z0PIWf{4uOFBWlm7|A;UK1(bDn)!Z zuD=320ticB?6hHLqc;)Sypv= z^wZV;^YR^$6l}y^n2!SX78jo3ndRBD>IlTu>?;kl5B=N8!pPZ210dPToP zYGF*j6*~@y{)bp1&3Zrh$^MYd7tG8A{j+EbX95>Ys()nd?-H#@oH49vL4N>|b>g8I z1<-s4;dtU1#(}Bd%_}8PCrqxoWus6viup$khOCBNwrsLm$fEymz|(_(;)CqZDNh7n zj)Q6)CR5})oyI>i8U*1wyT*(uXLYYwq(R(fSmXk-sESUSS%I6?nta+2dBEt?CvS#0 z*kkS31lY+H{9|<78MZq&|`ZjiytKR1l9NVs`U+FcVEYQC_HABbm`P&ERcz(DQ}Yjm+=O!QPy>* z7?aHI@D>NdcM&I;apNg*~Q*e@@N zWbV49=;2KpEuvOoWMpD${*f@xZYFHZ?E*B^<|v+o=HA|UHA05t-Kr%g}I+h#?(@;0pY*(kqO+eTWpO_9PoZ;cc22}U<;VUK>qXb&U24| z4)12(INy#)d3pU)S_t!aSe^!8sj+;Tg1CkcA>SNpWLu}MI`Ij^Y0k@+Fl>1+LG&8` z5Oq`==k)P5o^=iF@=vt{uZ4P4;|iIAykJXnULdFxY>juGeE1DV6JTCr`@za^(M5xk zP<20~lqXQLE|;VT^@>2<$afA2qhb;Q$3H#r5)zU%9kyibaaBhg&H_MTJfzTc?>H~h zHMyB6w-pNad{aa|XiupE!-vSlvYnv88hNyZCaFDuCWDEkdtg`y8Ef4!L}WSc0>LFl z98X2seF~$BNk&jv)>7;Zuxkrw;9I_(*`wrN`_cW^(VAMfHj&;GWBIhZyW_0y6v%^L?iw_h&h0TzIPd37AT z7H*x@JG{=21A>?&-KGz5AyTa{@X%dKb(- ztVYR!MqJ<}$d&{H)Knx{;pe@;5G96>GBITz4fEO?nSBx)%GF~E<5s?VB)L=hQRJ}$ zeuIlVlTKmweQ}<$z!8)AvxHOTb~#+|K|=d9!Z$2`NH_=rmQoUhQP!{^PeIBTwc`O{ zopK9MZ!S${%?fN~7G$G__YfVvk}&}?Y}S?QfQ$?#Z>sbmmk(S;4?}MF3N9$Q;9TAQ z3W%u(wFEg;Wu1iVMzo93+n|n{!N2~E3I*r!01B`>(q1|c9Rq~-n_t9qTyl>CLus*_ zr4CR5t#EhALChI`-NX9Izqk=@a*JM%I;AV(d>DT0Rio=CQH0G2&-R+WqI2-dndfJj zCgm7#2%$Y!aDntcK0)@dc7Lz){&`CD1I9)px(g%n%c}ajZn&f?fszR3D&zfewDRo* z>PYRA4cAab3HV~MltrLw*;7XLxhY$-?#;->+H6~Z8X zI7bey)%%G+zm$mPjRJo+dy!>{A~MXGX`N<1Tqgoo5PAZ7{5iSHwd;WKr%L%BSQhkvQI^#_GoPvnwt#Jif2 zhs?5j0!^U2UwMk2IkX~=O<#P0lAJmY3Tve`?2HF>AJ~ZbD_~Xu%TS-7(GLz*BG5Pbvz!noLIZ(;0;<))CvD4sr zHa{{Rn82TM?=rac^T5y;5X40g6Ef-Rd(h)jKtf9<&}l(Z5YY+|j^epZMUP~FFQd!! z4H@7VV{w<;=p!d!TfXICLq%r@ZYjj5@Kuhv>0<#`$^<^?qb$7+IoKm`?+joMP$St7 zcjyD3KY&#|`NB$ePlfq5mlhnQuneduL|8QwU>NizuEdHrwq=CPP6h z_XZYui0DSV`D5A+*(a`(kQGb#sCY^biCH(1M?7~OuOkrQ8G<}RLkKh0yezJNG+-4y z@RIoA)7x*yadM|uh3VW*VyIkTUX>q=QJV%K3rgAJUVOF{QO&XgcRs za|Q`WFiRl_4%p?XfiXVPDG75hNfFIUgj=eEeb5c!Qp}yk8xhS1i<_G*nol zU!*{rd#T{=yhVf67AT*4KlXe9DB@#13e@We24?_&<4#s{-|>gT%4l|M7I6&B^`Y_6 zSec{WK@zvYNy3kru!Uo&BJaV|29!}nh8lgPFcnKtB+2g`yI%W;*!qvUXqN%`?~-~X z0@^1zd1pZb$>gZ*p3#gxX5*8-HR(Us|F|_N*wnSV^&D-0k`z1y1o_)Fm+2ERv*V8- zoF)+Y*6NJ28o4+8Sb4kK9&$kA;D` z<5o|kdZYBnMQUXCdU)t>h>d5~^h4+V?Koroo)7G1o)Sm`a#`k=%Rs(c_ z3E9_LM8*$(U@qae{Vh`RC}K~v#2kugeIv^9_{Yyo^L;|Ox>Fj|3|u<46(hS#mnXH8 z_M!AW56oWc*IQ7C%c|iA(X7nF8Wh!%W!1>((b46M42%6^l9Vsk*^jT8OKjc6)Fj^! zmfOy#9*;1sw6-|_72m}dY(m`ArZwJ6KqC3N)vEZT^|J3(yq`9nZe3ADs^(r| zGv^+<&_D50#KshEkSiy)4T)WIqLpJ$m~9zTps7`HZ&Cfosg?!V9rmKC)%4C5%Z%TE z8{_k!j@~l%tpK{m(mc+Y8`tcCYA|obT$rC<_TCRgc1DE<9UBBwnx9@T1gMz~%sHB) zGBO~x`)6V!axv6okvaBvYb)+3vVUSamOv;zYJr-_0BhRC{SrxMO-)|)jmobwhyQ*r zEong;nyW6sy2rj##ks&P*M9rPCAT(0=qmdXHOrPZ%M+uK0o{MI)XJo!{u?_YOOf&A zH#WM<-EdOg;Yn@r0fTh^ z`OlO^p4L6-4<4>{v{9*Cz$_bEzfqMH@=GAGJ4Z!RCUKzcfU+0nzO zj4U~v;=6oQYC-f^+019PoA~+K_Vp-3oroGDdVl`ak@4d`iqyrIIn*FH-5}fN;^nx$ znb%iz>G7UlJG>X?0-5Fpt#_34gaz{V$^rGNDGtGv9oWva=SacTs59(Ck;aOH4izmqZ|6 z$=kJ@RB=uQGvQQ0enO6q)m{1_(0Km4;&Mf!(|mh;Nx@o9O7cQgwCw4a%s*wumyXyU zduAmcx!c)}Y^T>deyQtcs~+EV*@bq2((JW)>jSaTILkfOS~1Lvy$V~`F36@7Po-Fd zwM754r56~g!e))8txq^Fa-LCKc&4KJ7LMpC;=7KW7g)%qE?*USRmA*n*>&EwW>9F_ zAYjeSRCaH^=3K&jHhQeYc34Q~ze(lv+tp=~2G_&dsg17ppLHC)KfYso;G?_2(!3W3 zw*DE^xSuuTTBEM1D6Tw!>Zkn{S!?@Rcg;}cE!UU8$>)Q Date: Mon, 27 Jul 2020 11:29:30 -0700 Subject: [PATCH 06/12] checking in --- content/blog/boolean_names.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/content/blog/boolean_names.md b/content/blog/boolean_names.md index 2005f58..57cc402 100644 --- a/content/blog/boolean_names.md +++ b/content/blog/boolean_names.md @@ -15,18 +15,20 @@ The book, _The Elements of Style_ 1, is a concise guide to writing En In English, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for boolean names is because boolean variables' negations have meaning as well; in writing "not disabled" is a double negative and is discouraged. In code, '!disabled', is also a double negative, and should be avoided. -A boolean name should give the reader more clarity as it's scope expands. In [Go](https://play.golang.org/p/i1W05p5EpAN), a boolean variable that exists for the scope of an if statement may have a short name ('ok'). If this variable was in scope throughout the function, it would become meaningless. +A boolean name should give the reader more clarity as it's scope expands. A boolean variable that exists for the scope of an if statement may have a short name ('ok'). If this variable was in scope throughout the function, it would become meaningless. ## Bad Boolean Names As with many things in software engineering, it is easier to find mistakes than to do something correctly the first time. Here are some naming conventions to avoid: -1. Names that are already a negation. 'notReady' and 'notProd' may make sense in one use case, but becomes confusing in a larger context. This can lead to code such as, `confA.useUAT = !confB.notProd`. This is both hard to read and ambiguous (what if there is a third environment). +1. Names that are already a negation. 'notReady' and 'notProd' may make sense in one use case, but becomes confusing in a larger context. This can lead to code such as, `confA.useProd = !confB.notProd`. This is both hard to read and ambiguous (what if there is a third environment). 2. Names that are not negatable. A name such as, 'sheets', has ambiguous meaning. It probably has something to do with a spreadsheet, but it is the writer's responsibility to prevent the reader from needing to do an investigation. -3. Names that are in negative form. These usually appear when the typical behavior is the negative form. For example, 'disabled'. Keep all the names in positive form to avoid a future headache explaining what the billing system does when it's "not disabled". Is it enabled, or is it just not disabled? +3. Names that are in negative form. These typically appear when the default use is the negative form. For example, 'disabled' for a service typically disabled. Keep all the names in positive form to avoid a future headache explaining what the billing system does when it's "not disabled". Is it enabled, or is it just not disabled? 4. Overly general names. As discussed earlier, this depends on the scope of the name. Avoid using a name such as, 'on'. It leaves questions in the reader's mind such as, "What is on?". The exception to this is typical boolean names used across code bases; Go's 'ok' is an example of this. +5. Negatable adjectives without context. 'bool customSize' is clear, but without the 'bool' context, the type is unclear. Ambiguity can be removed by prefixing 'is' or 'has' ('isCustomSize'). + ## Conclusion This blog post discussed a goal to aim at (good names), and several things to avoid (bad names). Combined, these will hopefully increase the readability of your software! -- 2.45.2 From c04869f876c8dffe3e37fc9f917b3f4b393d2192 Mon Sep 17 00:00:00 2001 From: jeff Date: Tue, 28 Jul 2020 10:02:18 -0700 Subject: [PATCH 07/12] checking in --- Dockerfile.prod | 4 ++-- README.md | 5 +++++ content/blog/boolean_names.md | 16 ++++++++-------- 3 files changed, 15 insertions(+), 10 deletions(-) diff --git a/Dockerfile.prod b/Dockerfile.prod index 37eb3ad..3bbb2f4 100644 --- a/Dockerfile.prod +++ b/Dockerfile.prod @@ -18,7 +18,7 @@ FROM golang:alpine AS build-webserver RUN apk update && apk upgrade && \ apk add --no-cache git -RUN go get -u git.simplesystems.tech/SimpleSystems/static-web-server +RUN go get -u git.simplesystems.tech/simplesystems/static-web-server # STEP 3: Combine static files and binary on fresh alpine image FROM alpine:latest @@ -31,4 +31,4 @@ COPY --from=build-website /src/public /app/public # Copy over static-web-server COPY --from=build-webserver /go/bin/static-web-server /app/ -ENTRYPOINT ["./static-web-server", "-rootDir", "public", "-port", "80", "-redirect"] +ENTRYPOINT ["./static-web-server", "-rootDir", "public", "-port", "80"] diff --git a/README.md b/README.md index 9c1d197..2c98ee8 100644 --- a/README.md +++ b/README.md @@ -19,6 +19,11 @@ To build the production site, run the following command: hugo --minify ``` +To build the Dockerfile, run this command: +```shell script +docker build --no-cache -f Dockerfile.prod -t docker.simplesystems.tech/simplesystems/website:latest . && docker push docker.simplesystems.tech/simplesystems/website +``` + The resources will be stored in the `./public` directory. ## Managing Job Posts diff --git a/content/blog/boolean_names.md b/content/blog/boolean_names.md index 57cc402..70d5ad2 100644 --- a/content/blog/boolean_names.md +++ b/content/blog/boolean_names.md @@ -6,30 +6,30 @@ pdate: June 50, 2020 desc: Choosing a good boolean variable name --- -Choosing good names for variables is important. They are a form of documentation and can remove [complexity](http://localhost:1313/blog/complexity/) from code. Using a bad name for a variable leads to confusion, bugs, and wasted engineer time. In this blog post I will discuss what makes a [boolean](https://en.wikipedia.org/wiki/Boolean_data_type) variable name good or bad. +Choosing good names for variables is an important art for software engineers to master. Variable names are documentation and can remove [complexity](http://localhost:1313/blog/complexity/) from code. Using a bad name for a variable leads to confusion, bugs, and wasted engineer time. In this blog post I will discuss what makes a [boolean](https://en.wikipedia.org/wiki/Boolean_data_type) variable name good or bad. ## Good Boolean Names -Boolean names should be negatable, and in the positive form. These names should be clear and concise just as all variable names should be. As the scope of the variable increases, it's level of description should increase as well. +Boolean names should be [negatable](https://www.yourdictionary.com/negatable) and in the positive form. They should be clear and concise just as all variable names should be. As the scope of the variable increases, it's level of description should increase as well. -The book, _The Elements of Style_ 1, is a concise guide to writing English. Some rules can be used as a guide for writing code as well. For example, rule 11, "Put statements in positive form," can be applied to naming boolean variables. In code, there is one additional requirement: the statement must be positive as well. 'enabled' is in the positive form and a positive statement. 'disabled' is in the positive form, but is a negative statement. 'notEnabled' is both in the negative form and a negative statement. +_The Elements of Style_ 1, is a concise guide to writing English. Some rules can be used as a guide for writing code as well. For example, rule 11, "Put statements in positive form," can be applied to naming boolean variables. In code, there is one additional requirement: the statement must be positive as well. 'enabled' is in the positive form and a positive statement. 'disabled' is in the positive form, but is a negative statement. 'notEnabled' is both in the negative form and a negative statement. -In English, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for boolean names is because boolean variables' negations have meaning as well; in writing "not disabled" is a double negative and is discouraged. In code, '!disabled', is also a double negative, and should be avoided. +In English, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for boolean names is because the negations of boolean variables have meaning as well; in writing "not disabled" is a double negative and is discouraged. In code, '!disabled', is also a double negative, and should be avoided. A boolean name should give the reader more clarity as it's scope expands. A boolean variable that exists for the scope of an if statement may have a short name ('ok'). If this variable was in scope throughout the function, it would become meaningless. ## Bad Boolean Names As with many things in software engineering, it is easier to find mistakes than to do something correctly the first time. Here are some naming conventions to avoid: -1. Names that are already a negation. 'notReady' and 'notProd' may make sense in one use case, but becomes confusing in a larger context. This can lead to code such as, `confA.useProd = !confB.notProd`. This is both hard to read and ambiguous (what if there is a third environment). +1. Names that are already a negation. 'featureTurnedOff' and 'notProd' may make sense in one use case, but becomes confusing in a larger context. This can lead to code such as, `confA.useProd = !confB.notProd`. This is both hard to read and ambiguous (what if there is a third environment). 2. Names that are not negatable. A name such as, 'sheets', has ambiguous meaning. It probably has something to do with a spreadsheet, but it is the writer's responsibility to prevent the reader from needing to do an investigation. -3. Names that are in negative form. These typically appear when the default use is the negative form. For example, 'disabled' for a service typically disabled. Keep all the names in positive form to avoid a future headache explaining what the billing system does when it's "not disabled". Is it enabled, or is it just not disabled? +3. Names that are in negative form. These typically appear when the default use is the negative form. For example, 'disabled' for a service typically disabled. Keep all the names in positive form to avoid a future headache explaining what the billing system does when it's "not disabled". Is it now enabled, or is it just not disabled? -4. Overly general names. As discussed earlier, this depends on the scope of the name. Avoid using a name such as, 'on'. It leaves questions in the reader's mind such as, "What is on?". The exception to this is typical boolean names used across code bases; Go's 'ok' is an example of this. +4. Overly general names. As discussed earlier, this depends on the scope of the name. Avoid using a name such as, 'on'. It leaves questions in the reader's mind such as, "What thing is on?". The exception to this is typical boolean names used across code bases; Go's 'ok' is an example of this. 5. Negatable adjectives without context. 'bool customSize' is clear, but without the 'bool' context, the type is unclear. Ambiguity can be removed by prefixing 'is' or 'has' ('isCustomSize'). ## Conclusion -This blog post discussed a goal to aim at (good names), and several things to avoid (bad names). Combined, these will hopefully increase the readability of your software! +This blog post discussed a goal to aim at (good names), and several things to avoid (bad names). Combined, these will hopefully increase the readability of the software you write! 1 https://tinyurl.com/y3uxhzxc -- 2.45.2 From 06861e15793c91fe8ff2c8fce61d26669465f500 Mon Sep 17 00:00:00 2001 From: jeff Date: Tue, 28 Jul 2020 22:33:40 -0700 Subject: [PATCH 08/12] checking in --- content/blog/boolean_names.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/content/blog/boolean_names.md b/content/blog/boolean_names.md index 70d5ad2..ab9d385 100644 --- a/content/blog/boolean_names.md +++ b/content/blog/boolean_names.md @@ -13,19 +13,24 @@ Boolean names should be [negatable](https://www.yourdictionary.com/negatable) an _The Elements of Style_ 1, is a concise guide to writing English. Some rules can be used as a guide for writing code as well. For example, rule 11, "Put statements in positive form," can be applied to naming boolean variables. In code, there is one additional requirement: the statement must be positive as well. 'enabled' is in the positive form and a positive statement. 'disabled' is in the positive form, but is a negative statement. 'notEnabled' is both in the negative form and a negative statement. -In English, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for boolean names is because the negations of boolean variables have meaning as well; in writing "not disabled" is a double negative and is discouraged. In code, '!disabled', is also a double negative, and should be avoided. +In English, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for boolean names is because the negations of boolean variables have meaning as well; in writing, "not disabled" is a double negative and is discouraged. In code, '!disabled', is also a double negative, and should be avoided. -A boolean name should give the reader more clarity as it's scope expands. A boolean variable that exists for the scope of an if statement may have a short name ('ok'). If this variable was in scope throughout the function, it would become meaningless. +A boolean name should give the reader more clarity as its scope expands. A boolean variable that exists for the scope of an if statement may have a short name ('ok'). If this variable was in scope throughout the function, it would become meaningless. ## Bad Boolean Names As with many things in software engineering, it is easier to find mistakes than to do something correctly the first time. Here are some naming conventions to avoid: -1. Names that are already a negation. 'featureTurnedOff' and 'notProd' may make sense in one use case, but becomes confusing in a larger context. This can lead to code such as, `confA.useProd = !confB.notProd`. This is both hard to read and ambiguous (what if there is a third environment). +1. Names that are already a negation. 'featureTurnedOff' and 'notProd' may make sense in one use case, but becomes confusing in a larger context. The following code is both hard to read and ambiguous (what if there is a third environment). +```golang -2. Names that are not negatable. A name such as, 'sheets', has ambiguous meaning. It probably has something to do with a spreadsheet, but it is the writer's responsibility to prevent the reader from needing to do an investigation. + confA.useProd := !confB.notProd + +``` + +2. Names that are not negatable. A name such as 'sheets' has ambiguous meaning. It probably has something to do with a spreadsheet, but it is the writer's responsibility to prevent the reader from needing to do an investigation. 3. Names that are in negative form. These typically appear when the default use is the negative form. For example, 'disabled' for a service typically disabled. Keep all the names in positive form to avoid a future headache explaining what the billing system does when it's "not disabled". Is it now enabled, or is it just not disabled? -4. Overly general names. As discussed earlier, this depends on the scope of the name. Avoid using a name such as, 'on'. It leaves questions in the reader's mind such as, "What thing is on?". The exception to this is typical boolean names used across code bases; Go's 'ok' is an example of this. +4. Overly general names. As discussed earlier, this depends on the scope of the name. Avoid using a name such as 'on'. It leaves questions in the reader's mind such as "_Which_ thing is on?". The exception to this is typical boolean names used across code bases; Go's 'ok' is an example of this. 5. Negatable adjectives without context. 'bool customSize' is clear, but without the 'bool' context, the type is unclear. Ambiguity can be removed by prefixing 'is' or 'has' ('isCustomSize'). -- 2.45.2 From 46816ac65154e9b3cf9ff7020848c4de2d0244c2 Mon Sep 17 00:00:00 2001 From: jeff Date: Wed, 29 Jul 2020 15:19:12 -0700 Subject: [PATCH 09/12] Updates from Steven. --- content/blog/boolean_names.md | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/content/blog/boolean_names.md b/content/blog/boolean_names.md index ab9d385..6b9adcc 100644 --- a/content/blog/boolean_names.md +++ b/content/blog/boolean_names.md @@ -9,22 +9,18 @@ desc: Choosing a good boolean variable name Choosing good names for variables is an important art for software engineers to master. Variable names are documentation and can remove [complexity](http://localhost:1313/blog/complexity/) from code. Using a bad name for a variable leads to confusion, bugs, and wasted engineer time. In this blog post I will discuss what makes a [boolean](https://en.wikipedia.org/wiki/Boolean_data_type) variable name good or bad. ## Good Boolean Names -Boolean names should be [negatable](https://www.yourdictionary.com/negatable) and in the positive form. They should be clear and concise just as all variable names should be. As the scope of the variable increases, it's level of description should increase as well. +Boolean names should be [negatable](https://www.yourdictionary.com/negatable) and in the positive form. They should be clear and concise just as all variable names should be. As the scope of the variable increases, its level of description should increase as well. -_The Elements of Style_ 1, is a concise guide to writing English. Some rules can be used as a guide for writing code as well. For example, rule 11, "Put statements in positive form," can be applied to naming boolean variables. In code, there is one additional requirement: the statement must be positive as well. 'enabled' is in the positive form and a positive statement. 'disabled' is in the positive form, but is a negative statement. 'notEnabled' is both in the negative form and a negative statement. +_The Elements of Style_ 1 is a concise guide to writing English. Some rules can be used as a guide for writing code as well. For example, rule 11, "Put statements in positive form," can be applied to naming boolean variables. In code, there is one additional requirement: the statement must be positive as well. 'enabled' is both in the positive form and a positive statement. 'disabled' is in the positive form but is a negative statement. 'notEnabled' is both in the negative form and a negative statement. -In English, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for boolean names is because the negations of boolean variables have meaning as well; in writing, "not disabled" is a double negative and is discouraged. In code, '!disabled', is also a double negative, and should be avoided. +In English, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for boolean names is because the negations of boolean variables have meaning as well; in writing, "not disabled" is a double negative and is discouraged. In code '!disabled' is also a double negative, and should be avoided. A boolean name should give the reader more clarity as its scope expands. A boolean variable that exists for the scope of an if statement may have a short name ('ok'). If this variable was in scope throughout the function, it would become meaningless. ## Bad Boolean Names As with many things in software engineering, it is easier to find mistakes than to do something correctly the first time. Here are some naming conventions to avoid: -1. Names that are already a negation. 'featureTurnedOff' and 'notProd' may make sense in one use case, but becomes confusing in a larger context. The following code is both hard to read and ambiguous (what if there is a third environment). -```golang - - confA.useProd := !confB.notProd - -``` +1. Names that are already a negation. 'featureTurnedOff' and 'notProd' may make sense in one use case, but they become confusing in a larger context. The following code is both hard to read and ambiguous (what if there is a third environment). +

confA.useProd := !confB.notProd

2. Names that are not negatable. A name such as 'sheets' has ambiguous meaning. It probably has something to do with a spreadsheet, but it is the writer's responsibility to prevent the reader from needing to do an investigation. @@ -32,9 +28,9 @@ As with many things in software engineering, it is easier to find mistakes than 4. Overly general names. As discussed earlier, this depends on the scope of the name. Avoid using a name such as 'on'. It leaves questions in the reader's mind such as "_Which_ thing is on?". The exception to this is typical boolean names used across code bases; Go's 'ok' is an example of this. -5. Negatable adjectives without context. 'bool customSize' is clear, but without the 'bool' context, the type is unclear. Ambiguity can be removed by prefixing 'is' or 'has' ('isCustomSize'). +5. Negatable adjectives without context. 'bool customSize' is clear, but without the 'bool' context, the type is unclear. Ambiguity can be removed by prepending 'is' or 'has' ('isCustomSize'). ## Conclusion -This blog post discussed a goal to aim at (good names), and several things to avoid (bad names). Combined, these will hopefully increase the readability of the software you write! +This blog post discussed a goal to aim at (good names) and several things to avoid (bad names). Combined, these will hopefully increase the readability of the software you write! 1 https://tinyurl.com/y3uxhzxc -- 2.45.2 From 58008d1e2a9d3f3533a1e281c644ac7f91ba02b9 Mon Sep 17 00:00:00 2001 From: steverusso Date: Thu, 30 Jul 2020 03:31:09 +0000 Subject: [PATCH 10/12] Styling for code blocks. (#23) Revert back to a code block. Style for code blocks. --- assets/simplesystems.css | 8 ++++++++ content/blog/boolean_names.md | 6 +++++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/assets/simplesystems.css b/assets/simplesystems.css index 44a9f49..1ab0f07 100644 --- a/assets/simplesystems.css +++ b/assets/simplesystems.css @@ -340,3 +340,11 @@ button.round, .btn.round { } .blue { --clr: #42A5F5 } + +pre { + background: #eee; + border-radius: 5px; + padding-left: 1rem; + color: black; + font-size: 0.95rem; +} diff --git a/content/blog/boolean_names.md b/content/blog/boolean_names.md index 6b9adcc..33061af 100644 --- a/content/blog/boolean_names.md +++ b/content/blog/boolean_names.md @@ -20,7 +20,11 @@ A boolean name should give the reader more clarity as its scope expands. A bool ## Bad Boolean Names As with many things in software engineering, it is easier to find mistakes than to do something correctly the first time. Here are some naming conventions to avoid: 1. Names that are already a negation. 'featureTurnedOff' and 'notProd' may make sense in one use case, but they become confusing in a larger context. The following code is both hard to read and ambiguous (what if there is a third environment). -

confA.useProd := !confB.notProd

+ ```go + + confA.useProd := !confB.notProd + + ``` 2. Names that are not negatable. A name such as 'sheets' has ambiguous meaning. It probably has something to do with a spreadsheet, but it is the writer's responsibility to prevent the reader from needing to do an investigation. -- 2.45.2 From 25ba6754ff10920755342ef44fb6f5bdcd33c131 Mon Sep 17 00:00:00 2001 From: steverusso Date: Thu, 30 Jul 2020 14:02:53 +0000 Subject: [PATCH 11/12] Style code blocks uisng the 'friendly' code style. (#24) Style code blocks uisng the 'friendly' code style. --- config.toml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/config.toml b/config.toml index ac8095d..d49234c 100644 --- a/config.toml +++ b/config.toml @@ -3,4 +3,7 @@ disableKinds = ["taxonomy", "taxonomyTerm"] title = "SimpleSystems, LLC" [markup.goldmark.renderer] -unsafe= true + unsafe= true + +[markup.highlight] + style = "friendly" -- 2.45.2 From 28e42dee813804964f7499b506db02b84f5513ed Mon Sep 17 00:00:00 2001 From: jeff Date: Thu, 30 Jul 2020 15:42:38 -0700 Subject: [PATCH 12/12] Correct the date. --- content/blog/boolean_names.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/boolean_names.md b/content/blog/boolean_names.md index 33061af..01ed83f 100644 --- a/content/blog/boolean_names.md +++ b/content/blog/boolean_names.md @@ -2,7 +2,7 @@ img: /img/yinyang-simplesystems.png title: "Boolean Variable Names" author: Jeff Russo -pdate: June 50, 2020 +pdate: June 30, 2020 desc: Choosing a good boolean variable name --- -- 2.45.2