|
I disagree, in a situation like:
CryptographicUnexpectedOperationException exception = new CryptographicUnexpectedOperationException();
I find this more readable:
var exception = new CryptographicUnexpectedOperationException();
Typing CryptographicUnexpectedOperationException twice in such a short space I think is a bit redundant
|
|
|
|
|
Intellisense does help. For reading, indentation is something I would prefer. It is opinion. I think MS wants to divide and rule. When did Britishers took over MS?
*Last 2 sentences are supposed to be humor.
|
|
|
|
|
d@nish wrote: When did Britishers took over MS?
We didn't. If we had, the Color class would be spelled properly!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Wait, that explains it. Those who have trouble typing a "u", can not type IEnumerable< Whatever the hell it is >. I now know the whole purpose of var. Enlightened.
|
|
|
|
|
It's a pity that we can't use a condensed "new" format like:
CryptographicUnexpectedOperationException exception = new ();
which means the same as:
CryptographicUnexpectedOperationException exception = new CryptographicUnexpectedOperationException();
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
var is handy in two places:
1) When using Linq and returning "An IEnumerable of something, gawddammit, but I have no idea what the compiler is going to call it"
2) To identify people whose code you can't trust because they have no idea or no interest in what type a variable should be. It may save five keystrokes to use var instead of IEnumerable<Customer> but it doesn't help understanding when you have to read the code later.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
OriginalGriff wrote: To identify people whose code you can't trust
|
|
|
|
|
I use var when I have some method to call that returns a humungously long-named type. I then immediately change it with the "Make Explicit" option. That way I don't have to type it out in full or select from a potentially huge list of intellisense suggestions.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Fine by me - it doesn't leave the var in the final code, or treat C# as if it was VB and "don't know, don't care" Dim
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
That var is obviously an int, and you didn't even save any characters there..
|
|
|
|
|
I didn't waste any characters either
|
|
|
|
|
Hmm.. OK fine, I'll accept that excuse.
This time.
|
|
|
|
|
HomerTheGreat wrote: I assume the next developer will be at least as smart as me, if not much much smarter (likely)
Not so. You have business knowledge that you will have accumulated over time. You shouldn't need to comment straight forward code to tell the future devs technically what it is doing, but to explain the business reasons behind it.
PooperPig - Coming Soon
|
|
|
|
|
Misspelled identifiers.
Inconsistent naming for related items.
C++ header files that group things by their access method (public: , protected: , private: ) rather than putting related items together.
Hungarian notation should die in a fire.
Software Zen: delete this;
|
|
|
|
|
|
Hmm. I agree with Joel but I stand by my dislike of the common Hungarian notation, despite Simonyi's original intent.
Software Zen: delete this;
|
|
|
|
|
Thank you, that's a very interesting article - I never new the Hunagrian notation was meant to be like that.
And I actually like it: It could be an easy way to improve the legibility of old legacy code by means of a simple Rename, and it could be done incrementally, at our own pace, without need to set aside extra time for refactoring.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Comments like this:
i=6; //set i to six
modified 20-Oct-19 21:02pm.
|
|
|
|
|
My main bug bears are
1. Excessive whitespace between code lines
2. In code comment,for that complex method that are so short they are as useful as the var keyword.
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
1. incorrect bracket placement
2. if (2 == var)
3. not enough whitespace
4. globals
|
|
|
|
|
Currently dealing with a codebase that uses magic numbers and tucks them into the window's hMenu member (and uses them from there)! Ghhgh!
The other nightmare offense in the code is using "m_" for:
a) Some, but not all, member variables.
b) Some, but not all, in function variables, including loop indexes.
c) Some, but not all, passed function parameters.
That was fun to get sorted - NOT. There were even a couple places where the same name was used in two or more different ways, so a project-wide replace would blow up.
|
|
|
|
|
|
-2. Swallowing an exception
-1. Throwing an exception with no message and just the generic "Exception" class.
0. Using try-catch for normal program flow..
(And these are just the rules to the exception )
|
|
|
|
|
Things that bug me...
1. Comments. Too often have I seen comments that made no sense, were outdated, wrong or overly obvious. In fact I've learned to ignore comments as they've never helped me in any way. I guess programmers can't write English...
2. Code that is copy-pasted. Often the cause of bugs.
3. Swallowing exceptions.
4. Non-Object Oriented code in Object Oriented languages.
5. Formatting, you've said it.
Bonus:
6. Not using brackets in if statements. Very dangerous...
I'm working for a company that has worked with VB since the start. The first employees have worked with VB even longer and used Clipper before that.
I've seen 1 through 5 all to often
I've come to hate 6 when we started doing C# and outsourced a project to another company. HORRIBLE!!! I read the code and didn't know if they meant it that way or if they had introduced subtle bugs...
A lot of samples I get from the internet have it too.
I probably forgot some stuff, but these are a few of my least-favourite things.
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
I like to mark other's code with the unsafe keyword. That's what it is for, after all.
Edit:
Really bad things:
- Stringly typing
- Similar to magic numbers: Literal values and strings all over the place instead of enums, resources or similar.
- Spaghetti code, or totally insanely structured code
- Global variables, including abuse of the session or caches
- managing data in dozens of separate variables instead of using even the most primitive kind of entity
- not understanding the framework, being unwilling to learn and contaminating the code with flawed homebrew solutions
The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript.
|
|
|
|