On Friday, August 17, 2018 at 8:53:15 AM UTC+8, Liam wrote:
>
> I find that one-concept-per-line, yielding more compact functions, is
> easier to focus on, as it reduces vertical eye scanning and scrolling.
>
> A single-line if stmnt and my switch example demonstrate
> one-concept-per-line.
>
> The thing is, what is cost with the current if else expression that worth
more to introduce another possible complications? Like my previous email
and other developers had implied, LOC doesn't matter. In the end, the
compiler knows what to do.
It's okay to do vertical eye scanning (we're doing it anyway while we're
coding/reviewing). When ternary logic is abused, we need to do vertical +
horizontal scrolling. Let's fuzzy-logic the proposal:
Scenario:
1. We use the temperature and color to build a display.
2. We roll in updates (yellow & orange) in 2 years time.
3, We measure the number of possible steps with +1 and sum them up to
weight its cost. Any sub-possible actions (e.g. number of replies in a
forums) are ignored.
CASE I - Ternary
-----------
1. On first build: (+1)
*color := temperature > 100 ? "red" : "blue"*
2. Implement Upgrades with yellow & orange, assigned to fresh developer:
2.1 search for the code (+1)
2.2 no idea what is ternary operator, google and learn (+1)
2.3 realize how it works, upgrade it with: (+1)
* color := temperature > 100 ? "red" : (temperature > 75 ? "yellow" :
(temperature > 50 ? "orange" : "blue") )*
2.4 submit to upstream. Got rejected by reviewer and request to change into
using if else and/or switch cases. (+1)
2.5 if the developer went frustrated because 2.4 wasted his/her hours of
research: raise a forum and go SPARTA (+1)
2.6 consensus achieved, implement: (+1)
* color := "blue" *
* if temperature > 100 {*
* color = "red"*
* } else if temperature > 75 {*
* color = "yellow"*
* } else if temperature > 50 {*
* color = "orange"*
* }*
2.7) Submit for review. (+1)
2.8) Reviewed and accepted (+1)
Total weight: +9
Total weight if the developer is not short-fused: +8
----------
CASE II - Using if else statement
1. On first build: (+1)
* color := "blue" *
* if temperature > 100 {*
* color = "red"*
* }*
2. Implement upgrades with yellow & orange, assigned to fresh developer:
2.1 search for the code (+1)
2.2 Understood it is a nested if else statement. Add yellow and orange
conditions: (+1)
* color := "blue" *
* if temperature > 100 {*
* color = "red"*
* } else if temperature > 75 {*
* color = "yellow"*
* } else if temperature > 50 {*
* color = "orange"*
* }*
2.3 Submit to upstream for review. (+1)
2.4 Accepted. (+1)
Total weight: +5
----------------------------------
Compare both processes:
CASE I (Ternary) - cost [8-9) points, possible forum discussion
CASE II (If Else) - cost [5] points
If we use time as the currency and learning curve as a metric, Case II is
cheaper than Case I since it is a fixed cost (notice the bracket). This
also means it's easier to transfer project from one person to another
(because it not hard to learn).
Also, new comer is not necessary referring to new developer. It can also
means season developer taking over a project he/she not familiar with. It
can also means maintainer trying to learn a new patch as well.
My point is, wouldn't it be expensive to implement ternary just for the
sake of saving a few lines of codes, which doesn't carry out any
significant computational performances?
-- BETWEEN --
temperature > 100 ? "red" : "blue"
-- VS ---
color := "blue"
if temperature > 100 {
color = "red"
}
-------
I find the latter is easier to understand because it uses standard coding
comprehension and without needing to research with google; which is a hell
for new comer since trying to search "?" towards "ternary operations"
without bugging a senior for the first time is scary googling experience.
p/s: I'm sorry if I'm harsh but I must be straight about protecting the
simplicity of this language that I greatly fell in love with after dealing
magics and horrors across Ruby, Python, C, C++, POSIX, etc. Go is
beautifully crafted from learning to development; to process, and to
release and distribution management standpoints. It's simple to understand,
to learn, and to use.
go fmt aspires to produce an odd sort of poetry, which I find inefficient.
> It's especially bad in GitHub commits.
>
> Go fmt standardizes code and facilitate self-learning, so that the new
comer doesn't need to wonder around asking basic questions about
formatting, how to write this and that etc. This encourages them to talks
more about "problem", "algorithm" or "solution" to solve a problem, not
mingling with the language itself in the conversation with the seasoned
veterans. It is odd because it is the first language that provides such
tool to scrutinize codes for free, out of the box.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
