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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.