IDK why I get annoyed by underscores before private member names... Is i it useful or just an old relic?

Visual aid

@iiii how...

C# has a private keyword?

In Python and other languages maybe, as scope doesn't exist - but in C# this would decrease readability.

Same with Hungarian notion.

You not supposed to in C++. Reserved for standard libraries.

Edit: I like to use "m_" to denote member vars, and "s_" for static member vars.

@Demolishun it's only reserved if it contains two underscores, or starts with an underscore follower by an uppercase letter. (For things outside the global namespace, which includes fields of classes.)

@YADU I just avoid them. But thanks for the clarity.

@IntrusionCM you don't see the keyword when you use the variable.

@Demolishun I do too, I'm just being pedantic

I only see Java devs using _some_private_var

Grinds my gears when there's a private & public variable called the same thing though.

@IntrusionCM the privat keyword is only visible in the declaration.

Also the real hungarian notation was a useful idea that was then twisted and misunderstood.

Even with intellisense and all, some visible que helps reading code you did not write.

Underscore or lower first or whatever, it is faster than waiting for tooltips.

@Voxera I'm unsure about this.

In my opinion it's visual clutter that mostly is misleading, falling under the same as category overzealous comments.

You have to keep an additional thing updated, cause otherwise the meaning will be wrong and you might be completely misled.

Fun thing is I rarely use IntelliSense / tooltips - I'm quite used to working with tabs and skimming code..

I found hungarian notion disturbingly unreadable - mostly because my brain always chokes while skimming code because I have to interpret whatever abbreviation someone used there

@IntrusionCM yes almost all hungarian you likely have seen is bad since its usually tied to the value type and not as it originally was intended tied to context.

It was created in the microsoft office team and different prefixed indicated for example outer or inner margin or similar not integer or string.

And for clutter, if used consistently in the code base it works but if you jump between different projects with different standards or a code base without consistency it will be useless.

It also depends on the size.

For a small project, a few hundred classes it is not to hard, but with a 10 year old project with several thousands of classes built by several dozen developers over time, consistent use of code standards do help :)

If you use dart, it's the only way to declare private variables/methods coz there are no access modifiers ¯\_(ツ)_/¯

useful?
not sure. i just know it's *nice* to be able to tell visibility at a glance.

but i do it differently: starts with capital letter is public (property or function), starts with noncapital is private.

It shouldn’t be used. I agree with @IntrusionCM.

But for those who like to have visual aid, you can setup any IDE to show them bold, italic, or in different color.

Another thing is: You shouldn’t even care about it (in a decent language which has access modifiers).
Reading code, you‘ll never see a private var accessed where it‘s not allowed. And writing code, the IDE and compiler will also prevent you from using and suggesting that private var.
Same goes for hungarian type annotations.

This is a relic of the past when IDEs and dev tools were not as good or fast as today.
And of course it‘s also ok for languages that don‘t have access modifiers or strict types.

@Lensflare I partly agree but I have worker to much with legacy code to really buy into it ;)

And yes you can highlight things in the IDE, but not in bitbucket which also usually only displays the area around a change and not the entire file or class.

And there its quite helpful to quickly see what is public and what is private.
Yes, you can expand the area to show more and yes it happens that someone named a variable the wrong way, but it still helps often enough to be a time saver.

I know, if you have the luxury of never having to work in big legacy projects its easy to have higher standards for how things should work.

@Voxera That makes a bit more sense, though it remains a cludgy workaround.

I've worked on a fair deal of large legacy projects - and reviewing / review processes.

Especially in legacy projects it's necessary to upper the standards. After all that's where usually the most shit is found.

I know many devs like to go the short way and do review in a "I'll look at the code in the VCS browser and do it quick"...

But that's exactly what shouldn't happen - unless you really know the code in depth.

Check it out, understand it, make sure to get it right - otherwise the "reviewed by" is pretty much worthless. So yes, do check it out in an IDE and do the review where you can actually understand the code and not just read it and assume you know what happens.

The other thing - and that's what I found most disturbing in many legacy projects and where devs really are lazy bums - establish a working static analysis and automatical code guideline and keep it mandatory. Devs are lazy bums and always try to find a way to sneak by the automatic rules, I know some who are absolutely against it "cause then they have to spend time fixing it".

... But in legacy projects, static analysis and enforcing automatic coding guidelines can fulfill wonders.

Especially when the code is such a mind-blowing piece of shit that a human cannot even fathom to unwind the crazyness - e.g stuff like manual assignment by reference, intended weak typing for object conversion, etc.

I get your point about legacy projects, but the way you fix it is in my opinion wrong.

Don't add more cludgy and possible harmful workarounds to an already mutilated codebase, rather try to establish a hard rule base to ensure it gets unscrewed over time.

Note that "over time" doesn't mean that it will ever be finished - it can take years to unlimited time to get it done. But every small piece contributes to the large target.