The Pitfalls of Private Variables in Programming
Written on
Chapter 1: Introduction to Private Variables
Once again, I found myself frustrated while examining the code for Flutter's deferFirstFrame(). This function allows developers to delay the rendering of frames until they are ready to display them later.
void deferFirstFrame() {
assert(_firstFrameDeferredCount >= 0);
_firstFrameDeferredCount += 1;
}
However, there's an issue. The variable _firstFrameDeferredCount is private, making it inaccessible. While there is a public property sendFramesToEngine that somewhat addresses the situation...
bool get sendFramesToEngine => _firstFrameSent || _firstFrameDeferredCount == 0;
... it still doesn't enable me to monitor how often deferFirstFrame() is invoked. If I want to determine if I'm calling it excessively, I find myself at a loss.
Although this isn't as dire as issues with the markdown parser, where tracking the current block of text was impossible, it still leaves me feeling annoyed.
Section 1.1: The Challenge of Private Variables in Flutter/Dart
In many programming languages, you can control the access levels of getters and setters independently. For instance, in C#, you might write:
public foo { get; private set; }
In contrast, Flutter/Dart employs a convention where any variable prefixed with an underscore is designated as private. While this approach contributes to cleaner code, it also leads to complications, such as how to create a protected variable. Fortunately, there is an annotation available for this purpose.
While it's not insurmountable—renaming the getter or setter can be a workaround—finding an intuitive name for something like sendFramesToEngine can be a hassle.
Subsection 1.1.1: The Usefulness of Private Variables
It's essential to clarify that private variables are not entirely without merit. They can serve as indicators for elements that should be used cautiously, like the progress in an animation. However, if a developer is aware of the implications, they should have the ability to adjust a variable.
When private variables are embedded in public code, it sends a message that "this will never be needed by anyone else." While this might hold true for certain cases, it often complicates the developer's experience.
I've noticed that many advocate for private variables due to "code maintainability." While I appreciate the importance of understanding which code interacts with others, modern IDEs are quite adept at tracing these relationships.
I can't recall a situation where I thought, "I wish this code were private." Instead, I've often found myself thinking, "I want to test this private class—how can I do that? I guess I’ll have to make it public."
Section 1.2: The Frustration of External Code
The frustration intensifies when dealing with code written by others. When a fellow developer opts for private variables, it feels as though they are implying, "I know better than you, and you will never require this code." This attitude is infuriating.
I would prefer a system that doesn't mandate privacy but instead provides indicators for when a variable should be private, similar to Python's philosophy.
Ultimately, programming is about resolving issues. Introducing arbitrary barriers to problem-solving is counterproductive. While sometimes these barriers may seem inconsequential, wouldn't it be better to eliminate them entirely?
Chapter 2: Additional Resources
For further insights, check out the following videos:
Stop Making Private Variables feat. BadCop | 058 - YouTube
This video discusses the implications of using private variables in programming and the challenges they present.
Why you should NOT make everything PUBLIC! - YouTube
This video explores the necessity of maintaining certain variables as public and the risks associated with excessive privacy in code.
If you enjoyed this article and wish to stay informed about my future writings, consider using my RSS app, Stratum, available on iOS and Android. Don't forget to explore my language learning app, Litany (iOS, Android).