|
Eddy Vluggen wrote: explain a junior ONCE
That's once too many.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
"this" was introduced for a reason and should be used.
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
class uhoh
{
bool yay;
uhoh(bool yay)
{
this.yay = yay;
}
}
... is usually the only time I want to use "this".
Unless there was another "uhoh" being involved in an uhoh function. Which is probably not good practice.
|
|
|
|
|
Can you explain the reason? 
There is no good argumentation. "This" is used for the nut-cases who don't want to prefix with an underscore, and it is one of the most abused keywords, littering code without adding ANY value whatsoever.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: prefix with an underscore
 Yuck, filth, "littering code without adding ANY value whatsoever".
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote:
Yuck, filth, "littering code without adding ANY value whatsoever".
There's also a link somewhere in these posts to an article from Joel Spolsky. There have been various ways of indicating that something is a member, as opposed to a local variable. How do YOU differentiate between the two?
class X
{
private int i;
public int I { get { return i; }
public X(int someI)
{
this.i = someI;
int i = I;
}
}Looks better than prefixing the stuff, but there's hardly any hint that it is a private member or a local variable. It is obvious that I must be something public, either a field or a property. It'd also cause trouble with translating to VB. A simple workaround is using this to indicate the member;
class X
{
private int i;
public int I { get { return this.i; }
public X(int someI)
{
this.i = someI;
int i = I;
}
}The prefix is merely there to indicate that it is a member that is being referenced. I'd be writing the same as below;;
class X
{
int _i;
public int I { get { return _i; }
public X(int someI)
{
_i = someI;
int i = I;
}
}No confusion, and the minimal amount of symbols to convey all the information I want; everything private is recognizable by the underscore, everything public starts with a capital (similar as the recommendations) and everything local start with a non-capital.
The value that it adds is that it makes the naming predictable and consistent, makes it easier to spot errors and read the code. It is something that I found that does not cost time, but saves me time.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Better auto complete systems don't need this. as a crutch to figure out what they should be offering as suggestions. It may have been useful a decade ago but belongs on the rubbish heap today.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging 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
|
|
|
|
|
Eddy Vluggen wrote: Should I prefix each class with a complete namespace
Maybe not each, but I've found that some namespaces use way too simple names to be safe to use without! E. g. in C++ I never use using namespace std, since it clutters the global namespace with many symbols that are common enough that they may clash with just about every nontrivial application code.
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)
|
|
|
|
|
Eddy Vluggen wrote: You explain a junior ONCE that everything that does not have a modifier is private.
No. It isn't. The default for types is "internal" , but the default for class or struct members is private.  So basically omitting the access modifier applies a different meaning to different elements. For that reason I prefer code with explicitly stated modifier.
|
|
|
|
|
I gotta call foul on removing the private access specifier. In C# the default is private while in VB it's Public. I absolutely hate that and really dont want to have to remember what the defaults ars supposed to be when scanning over code for problems.
|
|
|
|
|
Dave Kreskowiak wrote: In C# the default is private while in VB it's Public. I absolutely hate that and
really dont want to have to remember what the defaults ars supposed to be when
scanning over code for problems.
I hate that it's public in VB.NET too, but it does not change the way I look at C#.
Having tried it, for several months, in both languages, to me, the benefit outweighs the possible disadvantage of confusion.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
What benefit? Saving 4 keystrokes?
|
|
|
|
|
I'm not into saving keystrokes; but it does convey the same information using less symbols. For your comparison:
procedure Test()
begin
end
void Test()
{
}
Would you like to imply that we use "{" and "}" merely to save keystrokes? You cannot deny that C# is a bit more readable than COBOL. Still, feel free to state the obvious if you feel like you have to 
It's a non-discussion. Try
11 + 2 = 13
Eleven plus two is thirteen Would we prefer the first version, just to save keystrokes? And which of the two explains the fastest what is going on?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I like to be explicit in my code. There is no doubt in my intent. I just find it a bit strange that "private" is the only exception to access modifiers where you have to be explicit about everything but only because it's default. I'm just saying that the access modifier shouldn't have a default forcing you to be explicit in your intent and (granted hopefully) think about what you're doing.
I am happy to say, as the other replier pointed out, that I'm not one of those that needs to be "saved from himself" because VB made everything Public by default and that's what generates tons and tons of bad "public everything" code.
I don't believe that the problem is with VB. I believe the problem is with the education and the lax standards of what should be taught in school. I've has more than few degreed grads that couldn't tell me the difference between public and private. I've also heard most of those same grads say they've never written an API, to which I call BULLSHIT since every application contains it's own API, usually for the sole consumer being the application itself.
I think the entire "private as default" or whatever modifier is default is a Band-Aid on a bigger problem.
EDIT:
And just for the record, I'm going to admit to being a hypocrite. I also rely on private being the default in my own code but, just because I do it, that in no way means I think it's a good idea.
|
|
|
|
|
Dave Kreskowiak wrote: like to be explicit in my code. There is no doubt in my intent
Hear! Hear!
Dave Kreskowiak wrote: "private as default" or whatever modifier is default is a Band-Aid
Testify, brother!
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Dave Kreskowiak wrote: I think the entire "private as default" or whatever modifier is default is a
Band-Aid on a bigger problem.
With the argumentation that one needs to save the developer from himself.
I'm sorry, but that only flies if you don't have any using-clause in your files. Be explicit in the class that you use, or accept the default behaviour.
Dave Kreskowiak wrote: I don't believe that the problem is with VB. I
Not? You just explained why it is
Dave Kreskowiak wrote: I've has more than few degreed grads that couldn't tell me the difference
between public and private. I've also heard most of those same grads say they've
never written an API, to which I call bullsh*t since every application contains
it's own API, usually for the sole consumer being the application itself.
Knowing the difference between the access-modifiers would be kinda basic knowledge. And no, unless it is intended to be consumed by the public, it is not a public API. If there's no SDK to download, then you're not building a framework.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
One of the common errors of OO design is making everything public. Being private by default means that this won't happen by accident, or out of sloppyness. i rather have the compiler complain that I forgot an accessor than having other programmers modify my internal state because I forgot to explicitely make them private!
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)
|
|
|
|
|
Eddy Vluggen wrote: there's a keyboard shortcut to automatically reformat in the VS-IDE.
which is a total broken disaster in VS2013 (for C++ at least)
|
|
|
|
|
- Wrong comments. Comments that pretend to explain the code, but the code and the explanation don't match.
- Rambling comments. At least they're not wrong, but the useful part is hiding.
- Unreachable code. Often mistaken for "defensive programming". Code that provably can't run is provably useless.
|
|
|
|
|
Re-using code blocks in different applications without checking that the pre-existing comments are relevant in the latest incarnation.
I keep finding examples of this in my archive. Stupid boy...
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
harold aptroot wrote: - Unreachable code. Often mistaken for "defensive programming". Code that provably can't run is provably useless.
Dunno about that one - I once inserted a check that I was 100% sure couldn't possibly fail, so I inserted a message saying this shouldn't be happening, and to please contact me. Thank god, it was a beta tester eventually seeing said message, not an actual user in production code - it turned out I was wrong on my 100% assumption... 
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)
|
|
|
|
|
I hope it wasn't provably unreachable, that would have bad implications for the fabric of reality.
|
|
|
|
|
I picture things like if ( name.Length < 0 ) ...
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
To CYA in the future wrap that in a debug only block and let the app die more messily otherwise.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging 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
|
|
|
|
|
All that you listed, especially the magic numbers. I would add "Not checking return values", assuming things are going to work is a recipe for pain.
OT:Chris Maunder wrote: site down
subconscious recollections of a nightmare?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
