Essential Practices of Responsible Programmers
Written on
Chapter 1: Understanding Code Responsibility
In today’s digital age, programming has evolved into an essential skill across various fields. As its popularity expands, more individuals are diving into the realm of coding, often without formal training, learning just enough to fulfill their job requirements. While some self-motivated learners can significantly enhance their skills over time, others may remain stagnant.
We must acknowledge those in the first group, whom I will refer to as professional programmers. They embrace accountability for their entire work, especially the code they produce, as it reflects their professional identity.
The significance of the codebase is intertwined with the coder's character. Therefore, I posit that responsible programmers avoid the following four practices.
Section 1.1: Choosing Meaningful Names
One of the most frustrating aspects of reading code written by others is encountering illogical naming conventions for variables, classes, and functions. For example, deciphering what variables named var0 and var1 signify can be quite challenging. Similarly, a function labeled doStepOne lacks clarity. This issue stems from a general deficiency in specificity. Multiple instances of var0 and var1 can exist in different contexts, leading to potential confusion.
Consider the task of tracking the width of an image in your application. You might be tempted to use variable names such as: float w; float width; float imageWidth; float imageWidthInPixels; Which of these options conveys the intent most effectively? Names like w and width can be vague unless they are utilized in a strictly limited context. In most scenarios, imageWidth or imageWidthInPixels are preferable. Modern IDEs typically offer auto-completion hints, alleviating concerns about variable length.
A further issue arises when naming conventions are disregarded. Every programming language has its own set of standards. Adhering to these conventions promotes coherence and enhances code readability. For instance, class names should not be written in lowercase, such as employee_record, but rather in camel case, like EmployeeRecord, to clearly indicate a new class declaration.
Section 1.2: Crafting Concise Functions
Refactoring is a common topic among programmers, recognized as a crucial practice for maintaining manageable code. However, it encompasses a wide range of activities, including algorithms, user interfaces, and documentation. Here, I will focus specifically on the importance of function refactoring.
A useful guideline I follow is to keep functions compact. In my experience, I seldom write functions that exceed 20 lines. While I do not actively monitor my code's length, this figure came to mind while writing this article! If your functions consistently surpass this length, it may be time to consider refactoring.
A few strategies include: - Breaking down larger functions into smaller, logically defined ones, each performing a specific task. - If several functions yield related output values, consider encapsulating these calculations within a dedicated class that contains separate methods for each calculation.
Chapter 2: The Importance of Code Documentation
The first video titled "4 Things I Wish New Programmers Would STOP Doing" highlights common mistakes that beginners often make, emphasizing the importance of clarity and ownership in coding practices.
Section 2.1: Effective Commit Messages
In contemporary coding practices, it’s rare for code to remain untouched after completion. Eventually, someone—often the original coder—will revisit it for debugging or performance enhancement. Experienced programmers stress the need for thorough documentation, particularly when using version control systems like GitHub.
While collaborating on significant projects, it’s standard to work on specific features in separate branches and commit changes regularly. How often have you encountered vague commit messages such as “an update” or “fixed a bug”?
Responsible developers should strive for clarity. Instead of ambiguous phrases like “fixed a bug,” a better approach would be, “fixed a bug that miscalculated the output value for the getUserBalance function.” Similarly, rather than stating “wrote another function,” specify “developed a function to validate user authentication in the UserAccount class.”
The essence of a commit message is to succinctly summarize the update while highlighting its critical components. Generally, affirmative statements devoid of ambiguity work best.
The second video, "Learning to Code as an Adult (Overwhelmed With Responsibilities)," discusses strategies for adult learners to navigate the challenges of coding amid busy schedules.
Section 2.2: Addressing Technical Debt
Have you heard of the Broken Windows Theory? This criminological theory posits that visible signs of disorder can lead to further deterioration in an environment. Applied to coding, neglecting "broken windows"—or poor code—can render a codebase increasingly unmanageable.
Whether your codebase is solely your responsibility or a collaborative effort, encountering subpar code should prompt immediate action. Responsible developers rectify poor code or alert the appropriate team member for resolution.
The principle to adhere to is straightforward: if you see something, address it. Allowing bad code to persist fosters a culture where new team members may mistakenly believe it's acceptable to ignore code quality. Over time, this accumulation of poor code can lead to an unmaintainable system, necessitating a complete rewrite—an arduous and costly endeavor that seasoned developers are all too familiar with.
Conclusions
Responsibility is a fundamental trait of a professional programmer. Embracing this responsibility is crucial for cultivating a clean and maintainable codebase. If everyone in our field commits to this principle, our collective work will become significantly more manageable.