Category Archives: Week 13

Code Documentation 101

Tommorow, Not Today

As with many classes, topics, and projects I have been a part of for the last few years, I see a consistent pattern. The unwavering focus on what’s going on in the present and never connecting the dots on how something might benefit me in the future.

Code documentation is just one of the many examples I could come up with to further my point. Up until now, all my work has followed the motto of “me, myself, and I,” failing to see that in the future that won’t be the case. Eventually, everyone will find themselves a part of a team, and there is nothing worse than an amateur teammate. Let’s take a deeper look into code documentation and why it will eventually be an asset to not just you but also your future teammates.

Type of Code Documentation

Internal Code Documentation: Intended for developers inside the organization.

  • Process Documentation: Provides high-level information like product requirements, roadmaps, notes, and reports.
  • Developer Documentation: Provides detailed instructions for developers and staff for building, testing, deploying, or maintaining the software.

External Code Documentation: Intended for developers outside the organization who integrate with the product or need to understand its code.

  • External Developer Documentation: Provides essential instructions for using source code, integrating with a product, and leveraging developer interfaces like APIs and CLIs.
  • Enterprise Documentation: Furnishes information for IT staff involved in software deployment, covering hardware requirements, sizing, operational needs, and maintenance guidelines.
  • Usage Documentation: Guides non-developer users on product utilization without relying on programmatic interfaces. Describes main functionalities within the product’s UI.
  • Just-in-Time Documentation: Supports developers as needed, often in the form of knowledge base articles, FAQ pages, or blog posts, added in response to new features or requirements.

Low-Level or Inline Documentation: Resides within the source code and explains details of specific code parts in isolation, such as the purpose of certain functions and arguments.

High-Level Documentation: Describes the architecture, design principles, implementation guidelines, or other broader concerns.

Walkthrough Documentation: Describes flows, patterns, and other important parts of the codebase, especially for developers who need to contribute to the code.

Food for Thought

Documentation might seem straightforward, but there are some issues that must be considered whenever starting a new document.

  • Knowing Your Audience: Depending on why/who you are writing your documentation for, you must consider their level of understanding when it comes to your subject.
  • Updating Documentation: It is very easy to push changes to your software and forget to also push changes to documentation. This starts a cycle with co-workers where the documentation falls behind and becomes uncomprehensible.

Tommorow

Embracing comprehensive code documentation is not just a practice for today but an investment in our collective future. As we transition from individual contributors to collaborative team members, the value of clear, well-maintained documentation becomes vital to future projects.

Source – https://swimm.io/learn/code-documentation/code-documentation-benefits-challenges-and-tips-for-success

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Addressing Technical Debt

Similar to my last blog, I wanted to focus on how to implement certain aspects of Scrum in an effective way. While exploring articles related to sprint planning, I came across a crucial aspect not covered in our class, technical debt. The article “How to Run an Effective Sprint Planning Meeting + Tips to Plan Technical Debt Work” by Cate Lawrence, provides strategies for making sprint planning less overwhelming while also highlighting the importance of preventative measures for technical debt. In this blog, I will focus on the technical debt portion of the article. Technical debt is a term used to describe future complications, that are time and resource intensive, that arise from expediting development instead of properly completing the product. It is the tradeoff between immediate gains versus long term consequences.

The article provides three steps for incorporating technical debt into sprint planning. The steps are:

  • Make technical debt visible

Recognizing potential issues and highlighting them for the team is important. Letting those issues accrue and not addressing them seemed like the opposite of the Scrum values. You should be adapting to unexpected issues or requests, not planning to have issues in the future.

  • Determine the business impact of each debt item

I could see how it may be enticing to take shortcuts during a Sprint. Convincing the team or management to not take these shortcuts and to tackle these issues will only help development, but it may be hard to do. Instead of focusing on all the technical issues in front of them, highlighting how the debt will come calling in the future felt like the appropriate response.

  •  Bring it to your sprint planning meeting

After visualizing the issues and showing why it would be best to deal with them now, including them in the next sprint plan is the final step.

Though not the main point of the article, it highlighted that technical debt was a neglected topic in sprint planning. I chose this article due to the steps, but also because it felt like something everyone should add to their Definition of Done. Even if everything “works” correctly with the code, knowing that there could be further problems due to the expedited nature of the sprint, the code should not be seen as done. It should not be ignored and should be addressed immediately or in the next sprint. Hopefully, these steps and the discussion on technical debt in the article will be helpful. In the future, I will try to address these types of issues using the steps, but also incorporate this into the team’s Definition of Done.

Link to the Article: https://stepsize.com/blog/how-to-run-an-effective-sprint-planning-meeting

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.