Why people code like this.

@CodeRed_dev Over the years I've been reviewing what patterns work and which didn't. I believe in most cases you're better of starting with simply: private int _x; Only if you need to use something externally: add accessors 1/2

@CodeRed_dev private int balance; public void setBalance(int value) { if(value < 0) balance = 0; else balance = value; }

@CodeRed_dev react has joined the chat

@CodeRed_dev Because not everybody should have access to your privates. But really, accessors and mutators make it easier to tell who is messing with what.

Because at some point in the future you may want to perform some validation before setting x, or in the case of a reference type, lazy load the type. This way you don't need to change any of the code that depends on those properties. Yes it's encapsulation, but this is why it matters.

@CodeRed_dev The reason, for anyone wondering, is to make sure X can't be changed by accident. You typically see it with projects that have multiple people working on it

@CodeRed_dev Also I have started writing variables as private by default, and then get confused to why it doesn't show up when I need it. Then I need to add those setterd and getters and my code just turns into garbage lol

@CodeRed_dev Because they've been brainwashed by OOP gurus.

@CodeRed_dev You might want to do some "magical behavior", like clamping values or updating another variable or... So this is the mark of someone that don't want to change all the value = value.x to value = value.GetX() later on.

@CodeRed_dev Because people are retarded. it's nice to teach these at school to learn that not everything should have access but in reality this screws many people. At some point it's better to just make whatever specific thing you are trying to access public.

@CodeRed_dev because OOP is a poison and makes people code in needlessly abstract ways that make things simpler in the short term but wildly over-complicated in the long term and ultimately makes everything inefficient

@CodeRed_dev I understand the reasons, but I don't like it 😂

@CodeRed_dev Its OOP. A programming style that was invented in the late 60's and should have stayed there.

@CodeRed_dev gotta make sure x doesn’t get changed on accident 🤬🤬

@CodeRed_dev I only do this if I specifically need some custom get / set logic, or I only need to be able to get but not set (or vice versa). Otherwise this is honestly just kind of unnecessary, goofy behavior IMO.

@CodeRed_dev It is called Encapsulation, and it is one of the principles of Object-Oriented Programming (OOP). Encapsulation offers many benefits, including protecting the internal state of an object, controlling access to data, and maintaining data integrity.

@CodeRed_dev Or worse, they put that in a single header file by itself.

@CodeRed_dev I’ll do this when I believe it won’t always be handled like that internally. I’ll also do it for consistency if it is grouped with things done similarly.

@CodeRed_dev Being radical about either option is a bit dumb. Encapsulation, debugging and mutate verification are main reasons to make them private. Less bloat is a reason for making it public. It depends on the team and project, not on the language or paradigm. Use both.

@CodeRed_dev So you can keep track of what is changing your variables. Using a method to get and set them is easier to follow.

@CodeRed_dev people think that adding complex rules to writing code will change the bad behaviors of bad coders 😔 they don't - they can get around this by getting pointer to the memory address - and they will 🙁 not using C won't help either 😮 they find a way - they always do😨

@CodeRed_dev I usually add a wrapper to the type if I need to debug. Regular breakpoint is easier then data breakpoints for all instances. We need better debuggers, tbh.

@CodeRed_dev Because they are dumb, dogmatic and don't care about computers

@CodeRed_dev Careful what you post, a whole generation was taught that this slop is the One True Way of Programming 😂

@CodeRed_dev Java ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

@CodeRed_dev This had my dying

@CodeRed_dev don't touch the raw with bare hands, we're not monsters

Back in the early 90s there was this new indoctrination going around in universities called software design and we were too young to realize it was bad and that we should fight it. A generation of lost souls after, some never found their way back may heavens rest easy on their UML souls.

@CodeRed_dev If it's possible or likely you'll have to handle *how* it is set and handle cascades or side effects, you have the boilerplate to expand from immediately. Otherwise, something will set it incorrectly and you're doing huge searches to find a bug where it was used improperly.

@CodeRed_dev Uh, you should read up about get and set

@CodeRed_dev There are a bazillion reasons why it's useful, but the main benefit boils down to just "control and traceability". Ex: If you want to lock x n y without get/set, it would be annoying as sin, with get/set you just shove a "if not locked" on the set.

@CodeRed_dev It's future proofing when working with more complex code. But game gevs can often get away with not doing the most optimally scaleable code when working on indie projects.

@CodeRed_dev If they pay $0.50 per line I’ll make my money’s worth

@CodeRed_dev It's your getter and setter. Its when you are paranoid your code is secretly trying to take you down

@CodeRed_dev because you can