|
While not explicitly aware of it, my understanding of the switch statement is that all the case declarations (which includes default) were merely labels, so I am not surprised you can stick the default anywhere in the list, I've just never seen it done before. Kinda like the idea though.
|
|
|
|
|
Note: The following is a personal statement of preference, not an invitation to a jihad.
Not really a programming misconception, but a coding style choice. For a very long time, starting in the mid-1980's through about 2010 or so, I used K&R braces exclusively. When I started writing C#, I used Allman[^] braces, following the style recommended by Microsoft and a couple of the books I was using.
As time has gone on Allman has become my preferred style. I have some vision problems due to age and glaucoma, so my code needs frequent blank lines to separate logical blocks. Allman braces provide white space that isn't merely cosmetic. I've even got an editor macro that converts K&R braces to Allman. I have a large body of C++ that I recently converted as part of a refactor and refresh effort on an old product that I'm maintaining.
Software Zen: delete this;
|
|
|
|
|
You don't need to fade it by saying it's personal preference when it's the Correct™️ way. Bring the jihad! 
My rationale is that other coding styles often waste horizontal space but use vertical space miserly. The control statement before the { needs to stand out so that you don't have to squint to read its condition. It also aligns the {…} and reduces the number of broken lines, which is another thing I try to avoid (hence 3-space indentation instead of 4 or even 8, whose users should be forced to edit all their spaces manually.)
|
|
|
|
|
Greg Utas wrote: edit all their spaces manually
As on a VT100, with an eighty-character limit.
|
|
|
|
|
The arrival of VT100s in our university computing lab was momentous! Our DECwriters were then used mostly for printouts.
|
|
|
|
|
When I started learning to program on the high school's PDP-11 in 1983, the lab had a mix of VT52s, one VT100, and a couple of Wyse VT100 clones.
And one DECwriter "hard-copy terminal" we had to use when we needed to print out our work.
|
|
|
|
|
Not an answer to the original question, however, since this part of the thread is dealing with style/formatting...
Thankful that VS now supports the .editorconfig specification.
I prefer and use 2 space indentation, as to avoid scrolling left and right to be able to read my code.
I also use { and } on their own lines at almost all times, the primary exceptions would be public: inline accessor get methods where exposing the member variable itself would be a bad idea...
ie.
private:
DWORD m_cbAllocated;
public:
inline DWORD get_Allocated() const { return m_cbAllocated; }
In those cases, I find that breaking the method down into multiple lines is overkill.
I also like white spaces after ( and before ) as long as it is not an empty construct. It simply makes it easier for me to read.
ie.
if( ERROR_SUCCESS == ( lRet = RegOpenKeyExA( HKEY_LOCAL_MACHINE, rPF.sPath(), 0, KEY_READ, &hKey ) ) )
In comparisons to constants, I always like to have the constant on the left (see above). This serves two purposes... It is easier to see what I am comparing to without scrolling right past all parameters, and it ensures that a typo (say a missing '=' sign), doesn't compile if comparing to an lValue. (resulting in a bug)
ie.
LONG lRet = RegOpenKeyExA( HKEY_LOCAL_MACHINE, rPF.sPath(), 0, KEY_READ, &hKey );
if( ERROR_SUCCESS = lRet )
{
...
}
Not for everyone, but after doing this for 30+ years, it's what I'm used to, and no employer in their right mind is going to force me to change this late in the game.
Here's the complimentary grain of salt .
|
|
|
|
|
Visual Studio has quite extensive options for code reformatting according to your preferred style. The preferences are given by the logged in user. You may want to set up two user names, with different formatting preferences: Log in with one name, go to the end brace, delete it and retype it, and you have the code the way you want it. Log in with the other name, do the same exercise, and code is formatted the way it should be delivered to others.
|
|
|
|
|
|
I use Allman for C# but for Javascript(mostly Typescript) is make use of K&R.
I do this because it's the generally accepted style for both languages and I am used to swapping between them.
It's also because working as part of a small team within a larger group(a team of 5 developers within a group of 20+ developers) it's easier to follow the generally accepted standards, or rather code doesn't get past code review if it doesn't follow those standards.
At home I do the same, using Allman for C# and K&R for Typescript or any other form of Javascript - it just kind of 'feels' right.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
I try to do the same, but am working on a Java project that's using alman because the lead dev's brain locks up trying to do any other styles. He wanted to do C# capitalization rules too, but eventually yielded on that part because Android Studio's autocomplete is strictly case sensitive, and having to try and remember different casing styles for our code vs android code was blowing up everyone else's brains.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I prefer Ratliff style, but can see why you would like Allman if your eyesight was failing.
|
|
|
|
|
I always used such a style. Now, I know it has a father.
|
|
|
|
|
I always thought of the Allman style as "readable" style as opposed to "space-saving publishing" style. Matching braces always allowed me quicker reading of where blocks began and ended. I never knew Allman existed as I programmed Macs and other PCs.
|
|
|
|
|
I'm unaware that I suffer from any. 
But, related to "negative integers", one misconception which I have seen at least one person state is the idea that signed integers (twos complement) are lower level (more native to the hardware) than unsigned integers -- that the CPU has to work harder to perform unsigned math. I'm pretty sure that I saw someone state that you should avoid using unsigned integers because they're slower! 
|
|
|
|
|
Yes, I don't think that applies for most CPUs however, it is fairly well known that in programming GPUs with CUDA it is much better to use signed integers than unsigned because the overflow handling is much faster. Nvidia's GPU cores are known for having many odd limitations.
"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?"
|
|
|
|
|
1. That OO is a good idea.
2. That exceptions are a good way to handle errors.
|
|
|
|
|
|
That other programmers knew what they were doing 
|
|
|
|
|
|
That async execution does not mean it's parallel/threaded and it has varied behavior depending on the runtime.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
The longest programming misconception I've ever held is that JavaScript (ECMAScript) is "bad". It took me a long time to see JavaScript as (just another "assembly language") but I've finally made "peace" with JavaScript. I think...
|
|
|
|
|
This is how twos complement works. There are a lot of older architectures that use this.
|
|
|
|
|
That foreach loops in PHP scope and clean up their memory references. Spoiler, they do not! I fixed quite a few long outstanding bugs with unset() calls when I figured this out. I know its in the documentation but I bet quite a few of us don't RTFM on the looping structures.
|
|
|
|
|
For 30 years, I have thought readability was the "truth". Then I bought a book called "Clean Code" by Robert C. Martin and found clean code was this convoluted set of rules of hard to read code that made no sense. I am now aware that "readability" means "machine readability".
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
