By default, older versions of IE (<=8) will submit form data in Latin-1 encoding if possible. By including a character that can't be expressed in Latin-1, IE is forced to use UTF-8 encoding for its form submissions, which simplifies various backend processes, for example database persistence.
If the parameter was instead utf8=true then this wouldn't ...
In your code, you have made multiple changes:
destructuring assignment to access fields in the pages is a good change.
extracting the parseFoo() functions etc. is a possibly good change.
introducing a functor is … very confusing.
One of the most confusing parts here is how you are mixing functional and imperative programming. With your functor you aren't ...
Code is read much more often than it is written, so you should take pity on the poor soul who will have to read the code six months from now (it may be you) and strive for the clearest, easiest to understand code. In my opinion, the first form, with local variables, is much more understandable. I see three actions on three lines, rather than three actions on ...
It appears that these variable names are based on the abbreviations you'd expect to find in a physics textbook working various optics problems. This is one of the situations where short variable names are often preferable to longer variable names. If you have physicists (or people that are accustomed to working the equations out by hand) that are ...
If you are in doubt, it probably is too clever! The second example introduces accidental complexity with expressions like foo ? parseFoo(foo) : x => x, and overall the code is more complex which means it is harder to follow.
The purported benefit, that you can test the chunks individually, could be achieved in a simpler way by just breaking into ...
In layman's words:
The important thing is not the numbers of lines but the readability of the code.
Any fool can write code that a computer can understand. Good
programmers write code that humans can understand. (M. Fowler)
In the examples you gave, the second one is definitively easier to read.
Source code is for people to read.
Although it's one factor in deciding to split off a function, the number of times something is repeated shouldn't be the only factor. It often makes sense to create a function for something that's only executed once. Generally, you want to split a function when:
It simplifies each individual abstraction layer.
You have good, meaningful names for the split-...
Explicit else block
The first rule just pollutes the code and makes it neither more readable, nor less error-prone. The goal of your colleague — I would suppose — is to be explicit, by showing that the developer was fully aware that the condition may evaluate to false. While it is a good thing to be explicit, such explicitness shouldn't come at a cost of ...
Readability is a valid reason to learn to use whitespace:
const MyObject& obj,
const string& s1,
const string& s2,
const string& s3
Located over there the parameters won't get confused with the body of the function. By locating them on a different line you won't ...
Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.
Class names should normally use the ...
This is a pretty common problem for scientists. I've seen it a lot, and it always stems by the fact that programming is something you pick on the side as a tool to do your job.
So your scripts are a mess. I'm going to go against common sense and say that, assuming you're programming alone, this is not so bad! You're never going to touch most of what you ...
To answer your question about extant research
But has anything been written or researched on recognizing the point where striving for code brevity stops being useful and becomes a barrier to comprehension?
Yes, there has been work in this area.
To get an understanding of this stuff, you have to find a way to compute a metric so that comparisons can be ...
When I see a line like if (!lateForMeeting()), I read that as "If not late for meeting", which is quite straight-forward to understand, as opposed to if (lateForMeeting() == false) which I'd read as "If the fact that I'm late for meeting is false".
They're identical in meaning, but the former is closer to how the equivalent English sentence would be ...
Those two examples you gave are not functionally equivalent. In the original, the condition test is done after the "some other code" section, whereas in the modified version, it is done first, at the start of the loop body.
Code should never be rewritten with the sole purpose of reducing number of lines. Obviously it's a nice bonus when it works out that ...
Physicist here. Been there.
I would argue that your problem is not about the choice of tools or
programming paradigms (unit testing, OOP, whatever). It's about the
attitude, the mindset. The fact the your variable names are well
chosen at first and end up being crap is revealing enough. If you think
of your code as “run once, then throw away”, then it will ...
You have an invariant:
Only a single view (out of 3) is ever active (and visible).
Then, I suggest that you provide a function to switch the activity and visibility of ALL views at once:
This function will:
check if the view is already active, avoiding unnecessary work
set the view as active, and visible
set the other 2 views ...
It's more readable. A few reasons why:
Nearly every language uses this syntax (not all, most - your example appears to be Python, though)
isanae pointed out in a comment that most debuggers are line based (not statement based)
It starts looking even more ugly if you have to inline semicolons or braces
It reads top to bottom more smoothly
It looks horribly ...
You can find several published promotions or rejections of no-brace styles at here or here or wherever bike sheds are painted.
Stepping away from the bike sheds, remember the great OS X/iOS SSL bug of 2014?
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != ...
It's a good practice.
You are following the scientific method.
If you change several things before any testing, then the testing of each will be more difficult, and perhaps not reliable, since preconditions will be more difficult to prepare and the different changes can interact with each other in manners you didn't foresee.
The time you feel you are "...
Sounds nice, but I would prefer to have people responsible for committing code changes, not bots.
Besides, you want to make absolutely sure that those changes do not break anything. For example, we have a rule that orders properties and methods alphabetically. This can have an impact on functionality, for example with the order of data and methods in WSDL ...
Both are horrible, but the first is more horrible.
Both ignore Java's built-in capability to decide what characters are "numeric" (via methods in Character). But the first one not only ignores the Unicode nature of strings, assuming that there can be only 0123456789, it also obscures even this invalid reasoning by using character codes that make sense only ...
I personally prefer the first method of just IsAdmin(User user)
It's much easier to use, and if your criteria for IsAdmin changes at a later date (perhaps based on roles, or isActive), you don't need to rewrite your method signature everywhere.
It's also probably more secure as you aren't advertising what properties determine if a user is an Admin or not, ...
A thin person isn't necessarily healthier than an overweight person.
A 980 lines children story is easier to read than a 450 lines physics thesis.
There are many attributes that determine the quality of your code.
Some are simply computed, like Cyclomatic Complexity, and Halstead Complexity.
Others are more loosely defined, such as cohesion, readability, ...
Functions should normally be short, between 5-15 lines is my personal "rule of thumb" when coding in Java or C#. This is a good size for several reasons:
It fits easily on your screen without scrolling
It's about the conceptual size that you can hold in your head
It's meaningful enough to require a function in its own right (as a standalone, meaningful ...
Your case is an example of the introduce explaining variable / extract variable refactoring. In short, an explaining variable is one which is not strictly necessary, but allows you to give a clear name to something, with the aim of increasing readability.
Good quality code communicates intent to the reader; and as a professional ...
Firstly, magic values are avoided in programming by using variables or constants. CSS does not support variables, so even if magic values were frowned on, you don't have much of a choice (except using a preprocessor as SASS, but you wouldn't do that for a single snippet).
Secondly, values might not be as magic in a domain specific language like CSS. In ...