33
cowsay
3y

Putting 👏 _ 👏 in 👏 front 👏 of 👏 your 👏 properties 👏 doesn't 👏 make 👏 them 👏 private 👏

Comments
  • 10
    @Torbuntu I'm not trying to make the rant maintainable
  • 7
    👏 compromise on 👏 this my 👏 boiz because 👏 its EveryOther 👏 Word Bro 👏 - jake paul
  • 2
    /* My default style */

    private bool isSet; // really private

    private string _foo; // private but has public get/set

    public string Foo
    { get { return _foo; } }

    public string Bar;
  • 6
    It’s called a naming convention and it’s a fairly common one if not universal. All naming conventions (if properly governed) are intended to give context when reading code without having to cross check every reference. When you get used to it, it really does help.
  • 1
    @CrankyOldDev
    I'm aware that it is a popular convention. I just think it doesn't send the message very well. Besides, there are actual ways of hiding members of your API.
  • 4
    @renanpvaz I don’t think anyone actually believes that just adding an underscore makes something private. Do they?
  • 5
    @renanpvaz In Python there are no private variables but you can use _ to mark a variable intended to be private.
  • 3
    There is no _ in front of my property, just a bit of grass. I keep my doors locked for security, never had a problem.... (shit joke)💩
  • 1
    Only private is real private
  • 1
    @ViRaS There is also the __ prefix (name mangling) which makes it ugly to access a variable from the outside. Still not really private.
  • 1
    @thisisnikos @helloworld
    "we're all consenting adults here"
  • 3
    Jesus Christ this. It looks stupid and the amount of times I’ve seen it used incorrectly is baffling
  • 2
    @deadpixel I've been in a project using angular that every method that wasn't a lifecycle hook of the component had it, it was a style rule.
  • 2
  • 0
    It's legit and beneficial to use it. In languages where you don't have private properties it seems the message "dude, when you're using this property you're probably not using the library/class correctly".
  • 0
    @theCalcaholic not having private properties doesn't mean that you can't have privacy. I usually see people doing this underscore thingy as a workaround (that doesn't actually work) when they expose a class as API.
  • 0
    @cowsay In python (for example) you don't need actual private properties. The whole language follows the principle of proposing a style, not enforcing it.
  • 0
    @theCalcaholic I don't see, in this context, why follow a convention when you can actually enforce it's principle.
  • 0
    @cowsay Why should you enforce it? If anyone finds a proper use for that property, let him do so - you've warned him by preceding it with '_'.
  • 0
    @theCalcaholic what? Then what is the point of using it? Either the member is private or not.
  • 1
    @cowsay It's not as black and white as that.
    '_' marks a member which is meant for internal usage only. But why should I forbid anyone to use it differently - at their own risk?

    I have the impression that this is how people think in the Python community. And I think that there is a point to it. Why shouldn't I regard developers as mature persons who can decide how to use the API?
    I've clearly marked how I imagined it to be used, but they can do whatever they want with it.
  • 0
    @theCalcaholic okay. I'm going to stop here because I guess we'd just go on disagreeing. Still, I do respect your opinion.
  • 1
    @cowsay Im not even disagreeing with you. I just want to point out that there is more than one approach to proper software architecture and that some people might want to achieve something different than others.

    I think there are very good reasons for both approaches (let's call it the Javian and the Pythonic approach 😀).
    The Javian approach makes it easier for beginners as well as big teams to obey the coding conventions, because the JIT compiler enforces it.
    The Pythonic approach on the other hand allows people to use the language in very creative and elegant ways which might not even be considered by its creators. Of course it also allows them to write pretty bad code - the responsibility however lies with the developer not the interpreter.
Add Comment