|
Actually, that's "component-based" (programming): as in VB 6.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
if you regard this component has a function and an interface, it may be a class...
diligent hands rule....
|
|
|
|
|
At the risk of subjecting you all to 9gag, this is funny : https://9gag.com/gag/aMK72BP[^]
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I think that sentence violates the Geneva Convention.
|
|
|
|
|
That's cold man.
Repo Man
|
|
|
|
|
And that's when the crime rate dropped to 0 
|
|
|
|
|
So if you get caught committing a crime in Finland, they give you the skills to do a better job next time? 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Clean Code: I like it, at least parts of it.
But now I just recognized that some co workers interprets this, that it is enough having their code clean formatted text whise (indentation etc.)
Can be that I'm wrong, but I think they have missed the point 
modified 4-Sep-21 21:01pm.
|
|
|
|
|
Don't complain...
they could have missed it anyways and leave it unproperly formated. 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Spot on ... upvoted 
|
|
|
|
|
Thanks
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Are they putting lipstick on a pig?
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I think more of dressing the (code) monkey with silk...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Well, I recently saw some code in which the "o" was left out of a variable named "count", sooo...
|
|
|
|
|
Unfortunately much of our field is littered with terms like "clean code", "Agile", "SOLID" but without concrete instructions, if you will, on how to implement those concepts. And lacking code reviews...and lacking people who know what they are doing though they claim they know...it's a mad mad world.
I still have no idea how to explain SOLID to a junior developer (heck, or a senior developer) and I still have no idea who the heck Liskov is/was.
[edit]OMG. I thought it was guy! Barbara Liskov - Wikipedia[^] [/edit]
|
|
|
|
|
Marc Clifton wrote: Unfortunately much of our field is littered with terms like "clean code", "Agile", "SOLID"
And "readability".
Marc Clifton wrote: I still have no idea who the heck Liskov is/was.
I looked for actual studies on "readability" at one time. There must be some given how much developers use that term to justify almost anything. There was one study that involved fonts used in marketing materials (and it was probably printed marketing also.) As I recall the conclusion was that 4 or fewer fonts should be used. Nothing else.
|
|
|
|
|
jschell wrote: 4 or fewer fonts
:cough: typefaces :cough:
But to stay off-topic, yes, so few web designers seem to have any graphic design education.
|
|
|
|
|
Readability is actually really important.
The reason you can't find studies on it is that it varies by language, norms, code history, etc.
I mean, sure, there are *some things* that are simply unreadable no matter what, but most often readability is highly subjective and team-based.
Making hard and fast rules about it is very impractical and verging - in my opinion - on impossible.
|
|
|
|
|
DeerBear wrote: The reason you can't find studies on it is that it varies by language, norms, code history, etc.
Nope.
The reason you can't find any studies on it is because one needs to first be able to measure something to do a study.
You can't declare that something is 'better' if you cannot define how to measure that it is so.
Would you sign a contract that said your code must be 'better' or you don't get paid unless the contract specifically stated how that would be measured?
|
|
|
|
|
Most readability responses are along the lines of:
- "They don't RTFM, so why write a good one",
- "Comments in code is bad",
- "I'm not good at (variable) naming".
Nothing to read. Unplanned code obsolescence!
Thank goodness(?) for Emoji's.
|
|
|
|
|
PhilipOakley wrote: Thank goodness(?) for Emoji's
Especially this one: 💩
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I have one person in my team who will insist on doing things their way, because of clean code and readability.
It's such a moot point, IMHO.
Practically speaking, you should stick to the following:
Structurally, you should keep the cyclometric complexity low --> you'll have cheaper A/B testing in the future, which is a good fallback strategy for unforeseen issues of all sizes.
Syntax wise, just copy whatever style is prevalent in the code-base already, and reduce inconsistencies --> cheaper refactoring in the future.
Quality wise, you should always aim for less lines of code, without resorting to ANY advanced language techniques --> less reading to understand the code, less esoteric bugs.
Just do those three things to drive costs down and quality up.
Everything else is pointless. The compiler doesn't care about the look and feel of the code and the user definitely doesn't care.
We should take a hint and stop caring so much too.
|
|
|
|
|
Programmers who can't be bothered to use linting tools are rarely concerned with cyclometric complexity, or maintenance cost, or refactoring. Also, it seems the broken window theory applies to software: if it's already crap software, most people won't bother with writing good code, resorting instead to the metric of lowest cost to write (even if it means the user or company pays the price many times over).
|
|
|
|
|
Andre_Prellwitz wrote: bothered to use linting tools are
Sigh...
Static checkers are useless. They were useless 40 years ago when I first saw them and just as useless now.
I have seen a static checked which tagged switch statements as being too complex. The 'solution' which some programmer implemented to fix that and which was reviewed and passed involved creating 40 objects every single time. 40 objects that could not even be created successfully every time. That code ended up in production. So it went from a very valid and correct idiom to one that failed.
If the teams consists of NOTHING but junior developers then maybe they might provide a benefit. But if there is even one mid level developer and that person actually takes code review seriously then that is going to be far more effective.
|
|
|
|
|
Agreed, static code analysis is designed to provide false positives over false negatives. What I actually meant was the simple linters that fix code style differences; if you cannot even agree on standards (rules such as "interface names should start with the letter 'I'", or "avoid Hungarian notation") then what are the odds you can agree on what's considered "clean"?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
