Welcome to the Disciplined Agile Value Stream Consultant Portal › Forums › Net Objectives Consultants › Net Objectives Podcasts and Blogs › Unreadability Is a Smell, Not a Pathology (MG)
- This topic has 18 replies, 3 voices, and was last updated 5 years, 10 months ago by
Al Shalloway.
-
AuthorPosts
-
September 21, 2016 at 12:52 am #28725
Al Shalloway
MemberThis is where I was hoping we would discuss Unreadability Is a Smell, Not a Pathology.
-
This topic was modified 5 years, 10 months ago by
Al Shalloway.
-
This topic was modified 5 years, 10 months ago by
Al Shalloway.
September 21, 2016 at 2:36 pm #28733Al Shalloway
Member“No effort was put into making it “elegant” – for instance, I declared all my variables with an explicit type”
I don’t think explicit types are not elegant.“You can do certain things that will make code less readable to almost any developer. You can do things that will make code more readable to almost every developer.
…but you can also do things that will make code more readable to some developers and less readable to others.”So why don’t you always do the 2nd option?
September 21, 2016 at 4:35 pm #28735Al Shalloway
MemberIn Java, explicit variable types are your only option.
In C#, var is objectively more elegant than an explicit type. It costs nothing but eliminates a point of coupling. As we’ve covered in previous conversations, it’s not the same thing as dynamic, which is an untyped reference like you would see in JavaScript.
This is actually kind of making my point. var objectively reduces coupling without any cost. dynamic objectively reduces compiler feedback with little benefit. As such, one sold be used always and the other should be used extremely rarely.
Whether code us readable, on the other hand, is subjective. Mostly it’s subject to what people know, somewhat to their experience, and a little bit to their preference.
For instance, the people who hate var the most usually think it creates an untyped reference and the people who think it makes code less readable trend to know what it does but not have used it long enough to realize it has, literally, no down sides. There are always a few hold outs with a stubborn preference that supercedes quality.
As far as why you don’t do the second one…I don’t know why people funny do those. Does something in this article make it seem like I’m arguing against them?
What do you think the thesis if this entry is?
September 21, 2016 at 5:31 pm #28742Al Shalloway
MemberThere are a few stubborn people who always want to make the argument that var adds quality to the code 🙂
It seems like you’re not making your point that it should be #2. Is that the point you’re trying to make?
September 21, 2016 at 5:40 pm #28745Al Shalloway
MemberNo. That is not my point at all. I want people to stop treating readability like it’s a quality and start treating it like a smell.
“That’s unreadable” is sometimes a valid indictment of code that has a serious problem but most of the time it’s a stockade in which the incompetent can hide from new ideas.
In the case where code is unreadable because of a real problem – a lack of cohesion, nonsensical names, et cetera – I want people to focus on the real problem, rather than the symptom of said problem.
Imagine we had an high incidence of a naturally-occurring auto-brewery syndrome in our population. The way we treat the phrase “that’s unreadable,” right now, is tantamount to taking all those people with auto-brewery syndrome and putting them through AA just because they smell like alcohol.
September 21, 2016 at 6:11 pm #28746Al Shalloway
MemberI’d leave out the three options and concentrate more on that point.
I’m not necessarily in favor of eliminating readability as a code quality. But I understand your point on suggesting it can be a smell. There are interactions between other qualities. E.G. Testability – is it a quality or a smell?
September 21, 2016 at 6:45 pm #28748Al Shalloway
MemberThat’s interesting. I have to find a way to reconcile the fact that I added those claims because they made the point more clear in Scott’s view and that their presence makes it less clear in your view.
I’ll have to noodle on how to do that for awhile.
Vis a vis you being in favor: I didn’t think any of you would agree. I was surprised – shocked even – by the degree to which Scott agreed with even the first cut of this entry, which was substantially less accessible than this one.
I’m fine with this being something that generates a little controversy. It’s okay for people to hear the occasional scuffle on Olympus every now and then. I think it will help people understand that this stuff is not settled and probably won’t be in any of our projected lifetimes. 🙂
As far as testability goes, if the criteria for a quality are as follows…
- There or absent in an objective way
- A property of the code, itself
…and I propose that they are, then testability would be a quality. It’s a compound quality – one that is built mostly out of other qualities. Then again, all the code qualities feed into each other. There’s nothing qualitatively different about it.
Readability does not meet either of the two aforementioned criteria so I don’t call it a quality and I don’t think anyone should. I’m not going to go to war with someone if they disagree but I’m also not going to start calling it a quality.
I think of it like the difference between cycle time and efficiency. Cycle time is not efficiency but it’s pretty much impossible to be inefficient with a low cycle time. Likewise, it’s hard to be readable and low quality but a group’s inability to read something does not mean that it is low in quality.
September 21, 2016 at 11:05 pm #28754Al Shalloway
Membervar ABSOLUTELY adds quality to code – it removes redundancy..
September 21, 2016 at 11:05 pm #28755Al Shalloway
MemberUpdated (but left the old one in place):
September 21, 2016 at 11:12 pm #28756Al Shalloway
MemberYeah, Amir. I agree.
Code qualities aren’t subjective beyond the veil of subjectiveness inherent in the uncertainty of the universe. Like you can’t know where a code quality is and how fast it’s moving with less error than Planck’s constant and there’s no way to know that there is even a universe and not just a “show” being fed into a consciousness.
Beyond those conceits, code qualities are matters of fact. The degree to which they are present are absolute.
var is an example of that. It compiles exactly the same. It refactors exactly the same. It tests exactly the same. In every way, it performs in exactly the same way as an explicitly-typed variable because it is a statically-typed variable. It just happens to be the compiler that is specifying the type of
var pi = 3.1415926547m;
rather than a human.If someone believes there is a downside, they should say what it actually is. Matters of preference carry exactly zero weight against a real thing like eliminating a point of redundancy.
Maybe we should have a separate thread for var.
-
This reply was modified 5 years, 10 months ago by
Al Shalloway.
September 22, 2016 at 1:45 pm #28760Al Shalloway
MemberThere is nothing absolute in life 🙂
September 22, 2016 at 4:10 pm #28762Al Shalloway
MemberThere are things that are so close.
There’s a chance that I could get to Philadelphia by jumping off my deck and flapping my arms really hard rather than taking a plane. I’m not going to try it, though.
var is in the same category.
September 22, 2016 at 4:17 pm #28764Al Shalloway
MemberNope.
Why didn’t you use var everywhere in your code example in your new blog?
September 22, 2016 at 4:18 pm #28765Al Shalloway
MemberBecause I didn’t want to have to deal with people who don’t understand that it is all upside.
Can you name a single downside?
September 23, 2016 at 3:20 am #28771Al Shalloway
MemberI can:
I have to learn what
var
is; I’m too lazy. -
This topic was modified 5 years, 10 months ago by
-
AuthorPosts
- You must be logged in to reply to this topic.