Eyy, someone who actually reads! Last time a post like this popped up it was like arguing with someone who was just reading of a list of "top 10 most popular buzzwords"
Facebook got caught having a flat text file being send around between employees to make accessing data easier. That text file contained tens of thousands of peoples username and password.
Also, have another look at that example code snippet though: that static variable is local to that function. It's a weird feature in c.
I've used it quite often in embedded code where a single variable was only for one function, and only for that one app/device. Wrapping it in a struct would've made the code needlessly more complex (that's a code smell). And yet, these static locals are very easy to refactor to one local to a struct. May the situation change, that's still an option.
They aren't saying never have complex boolean expressions...
That's not what I'm saying either. But I think this is to be judged on a case by case basis. And it can depend on your understanding of the context. I think there's simply too much nuance here to just say "this smells"
Not sure what your point is here. Of course inconsistent naming is a code smell. Do you want inconsistent names?
Of course not. But in some (uncommon in my experience) cases method names can be unclear or just plain impractically long. In such cases, I would rather see an exception to the rule than having to rely on a comment to explain the name choice.
I had a great example a couple months back, but I can't remember it right now. But here's a (bad) example of such a situation.
An example of this could be a button that triggers a click. You might call it BtnClick. Then the click event for it could be BtnClickClick. In this case, I'd rather see BtnClick_click. Ugly? Yes. Bad example? yes. But the idea is that it's more clear that the _Click action is seperate from the name.
There are arguments to be made either way, but normally you’d scope your variables in a way that the ones specific to a particular bit of code are not accessible from elsewhere.
They're arguing to do this:
c
int field = 1;
void may() {
do(field);
}
int field = 3;
void you() {
do(field);
}
int field = 3;
void be() {
do(field);
}
int field = 7;
void happy() {
do(field);
}
rather than
c
int field = 1;
int field = 3;
int field = 3;
int field = 7;
void may() {
do(field);
}
void you() {
do(field);
}
void be() {
do(field);
}
void happy() {
do(field);
}
A bad example of encapsulation would be:
class AClass {
private class HelloThere {
int a = 1;
int b = 3;
int c = 3;
int d = 7;
void DoStuff(AClass self) {
Do(a, b);
}
}
private HelloThere field = new();
void World() {
field.DoStuff(this);
}
}
Of course, there is nuance here. Is this class encapsulating enough that it's got a right to exist? That'll depend on the situation.
Also, c has local static variables. Depending on your use case, it might just be easier in c than in C# and similar.
c
// a method with a state, horrid in some contexts, great in others
void PrintCounter() {
static int count = 0;
Print(count);
count += 1;
}
And just in case you're still reading and curious:
csharp
#region PingPong
// hi! I am in a region, collapse me using your ide!
#endregion
Damn, suppose I won't just pass it as a pointer from the call site. That'd be so difficult to add an int to a struct
30 years my ass