Category Archives: Week 13

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’ or ‘ customer_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’ or ‘ customer_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.

Linting For Non-Inclusive Language

Last week we went over linting for non-inclusive language. During class, I was confronted with the idea that certain phrasing that I often use could be taken negatively. My last blog was about the best practices for software documentation. The blog I found mentioned inclusive language briefly at the end and didn’t go into much detail. Because of this, I decided to find a blog that focuses on how to write inclusive documentation.

The blog I found that went through this topic is “How to write inclusive documentation?” by Selvaraaju Murugesan. In this article, Murugesan breaks down how to produce inclusive documentation in five steps: (1) Use gender-neutral terms, (2) Choose a neutral and friendly tone, (3) Avoid using slang words, (4) Use visuals that are diverse in nature, and (5) Use the right terms when discussing accessibility and disability. The directions and reasons behind each recommendation were clearly explained with examples to aid in understanding.

Because writers do not know anything about their audience there are many cautionary steps that a technical writer has to take.  In the new day and age, writers should keep in mind to write in a gender-neutral way to avoid discriminating against women and people of the LQBT+. He also advised using wording that removes cultural bias. He steers clear of terms like “slave-master architecture” as well. He also mentioned that local slang words may be offensive so it’s best to avoid using them. Terms that can be considered judgemental, patronizing, or exhibit euphemisms should be avoided as well. 

As alluded to in my previous blog, I have experience checking for non-inclusive language because I worked on code for Libre Food Pantry and Thea’s Pantry. When working on the linters for these projects, I discovered that there was a linter that checks for non-inclusive language. I didn’t give too much thought about the changes that the linter suggested. It wasn’t until recently in class that I gave it more thought. I didn’t think about why using “simply”, “clearly, or “of course” could be an issue for the audience. It is important to avoid deterring others from using software or wanting to be involved in the tech field. I realized that it is important to recognize that not everyone will find something simple to implement so to imply that it will be is not the best choice when trying to be inclusive. 

After going through the class activity and reading the blog, I have gained a better insight into how to choose my phrasing carefully. Although it may be slightly difficult to break certain habits, I am now better suited to identify non-inclusive language and will apply my knowledge to future projects.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

Week 13 Clean Code

In my search for a topic this week, I searched for an article closely related to our homework and our last five Pogil activities. I kept it simple and looked for an article about clean code. I understand we have been loaded with tons of information about clean code but when was having more of something bad. I wanted to see different perspectives of clean code outside of class and what people inside the field or with experience opinions on. Allowing me to get insight from outside of class will be very helpful. Also, being able to have an open mind with coding can go a long way plus being able to see similarities with what I have learned and my own opinions. 

This article starts by describing the term “Spaghetti code” which refers to complex tangled code that is hard to decipher and causes frustration for everyone involved. This ties into clean code by emphasizing how is an integral component of software development and can only be maintained with practice. This comes with less team frustration and allows for any teammate to manage the code. Clean code is just not a statement of keeping the code tidy tightly but more of a form of communication that can be understood by everyone thoroughly. Software companies make big investments into clean code by hiring someone and paying them around $60-$100 an hour because of how vital it is for long-term success. An effective strategy to implement clean code is by grouping similar functions, utilizing whitespace, and “one idea per line” and “one action per statement”. To tie it all together your code must be consistent to adhere to agreed-upon team coding standards. Decisions that will help in the long run would be to add meaningful names, maintain simplicity, and apply comments effectively. 

With this article, I was able to learn a new term “Spaghetti code” that is self-explanatory and can remind me to keep my code simple and clean. I was able to connect many teachings from class including using meaningful names, abiding by team agreements, and utilizing whitespace. All these are valuable pieces in writing clean code that should always be in your mind when writing any piece of code. I was surprised at how much software companies invest in clean code and wasn’t expecting them to get paid that high. My main takeaway from the article was to keep my code consistent and simple. You may not think about these things but wanting to make things more complex can be a determent to all your previous work so being consistent will not only help you but your team as a whole.

https://reflectoring.io/clean-code/

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

AI as a Tool for Software Development

Within the past few years, AI has really made a name for itself. Whether it be through art, music, chatbots, or whatever else AI can take part in, AI has cemented itself into our daily lives. One area in which AI has become an integral part of is in software development, transforming various aspects of the process.

One of the greatest features that AI brings to software development is the fact that it can assist in generating code and finishing code as developers develop. Using existing patterns in databases for code, AI can generate code according to what the developer is trying to achieve. Say a developer needs to create a function that checks if a number is prime, returning false if it isn’t and true if it is; if a function that meets these requirements exists in a database, then the AI will simply suggest that function. 

Although using AI in this way is very useful for developers, they also need to be able to develop without it. AI can suggest code but that doesn’t mean that said code will perfectly fit into the program or that it’ll suddenly work thanks to the AI’s help. At the moment, it should just be used as a tool to make the development process easier and faster; although we may see these features and much more in the future. 

Another way in which AI can assist in the software development process is through analyzing the project timeline, workflow, and other such data and making predictions based on them. By analyzing previous projects, sprints, and other data in the development process, AI could create some insight and predictions that the project managers could take into account when dealing with current and future endeavors. These insights may include timelines, potential highs, lows, bottlenecks, roadblocks, and other such information that the managers could use to optimize the workflow and avoid issues. 

As with the developers and generated code, project managers should also have knowledge of management. AI’s suggested timeline, insights, and all that aren’t guaranteed but simply ideas based on what has happened in the past. It, like for coding, should be used as a tool but in this case, it should be used to see and suggest things that the human manager may not have anticipated or seen.

Overall, AI can be very useful in the software development process but this doesn’t mean that it is the savior for all issues within it. Like with any field one goes into, having knowledge of the fundamental ideas and practices are necessary if one wants to succeed. AI, as of now, is still in its early stages compared to what it is capable of and should be used with caution. AI was used to help write this post and I hope to be able to use it fully both now and in the future whether in my career or outside of it. 

https://www.zdnet.com/article/implementing-ai-into-software-engineering-heres-everything-you-need-to-know/

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

software design patterns

We’ve gone over a couple of design patterns in class this semester. Some that come to mind are the singleton and factory patterns, both of the creational variety. This latter half has been more focused on practical applications of software construction, taking a look into the Thea’s Pantry system that uses a microservices approach, but earlier on we were working with design decisionmaking and approaches.

A software desing pattern is a reusable solution to a problem that occurs often. The three main types of design patterns are creational, structural and behavioral. This is all well and good, but what do these types entail? I found this blog post from NetSolutions regarding the subject, and it gives a brief explanation of each as well as some examples.

Creational design patterns are solutions for the creation of objects and how they are used. The aforementioned singleton and factory patterns are creational because they dictate the way that objects are meant to be created based on the circumstances surrounding it. Singleton ensures a single instance of an object that can be called, while the factory is a sort of constructor of objects that utilizes an interface to form an object from sub-classes.

Structural design patterns relate to object composition to form better flexibility when working on a large-scale project. For example, an adpater is a structural design pattern that allows for incompatible interfaces to work together, creating greater flexibility in the program. The facade pattern is a sort of application of encapsulation and abstraction, allowing for the hiding of complexity with an interface, making it easier to work with.

Behavioral design patterns deal with separate objects and the way they share responsibility and communicate. The strategy design pattern is an example of this, where algorithms are put into a family where each algorithm is only called when it needs to be called, increasing efficiency. The observer pattern links one object to many dependents, notifying the observer object whenever any depedent has experienced any event.

It seems important to have these tools in your belt, considering that many of the problems that these design patterns solve occur fairly regularly even when developing different pieces of software. The one thing I would consider being wary of is using software design patterns at all times when you may not need it. For example, the factory pattern is best used when working on a fairly large project, but is not necessary at a smaller scale. Of course, when a project goes from small to large, a refactor may be called for, but perhaps the factory pattern is not the best tool for the job, it’s instead a builder or prototype. There is no one-size-fits-all solution, and so it’s also a skill to know when and how to use patterns and not just apply them randomly.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

Alex JS Lint

In class, we had the in class activity about inclusive and insensitive writing. This assignment was able to open our eyes on vocabulary choices that we didn’t even notice as being potentially harmful to others that might be reading our work. This got me thinking about if anyone else has been using the Alex JS linter and if they have posted anything about their feedback and experience while using it. From my searching I found a blog post called, “Refactoring condescending language with alexjs” by Suzanne Aitchison. This blog focused on their experience with the Alex JS linting tool and what led them to start thinking about their use of words and tone when writing their work.

The blog started with what got them thinking about their use of tone and content when writing . They mentioned how they were told to focus on words such as “easy” and “simply” because to some people the task at hand might not be so simple or easy to them which can be very discouraging and have them lose motivation. The Alex JS linter focuses on, “gender favoring, polarizing, race related, religion inconsiderate, or other unequal phrasing in text” which covers most of the types of insensitive ways of writing. In the author’s experience when they used it on their own work they had 104 warning of insensitive writing that all fell into common groups. Which happened to be the use of “easily”, “simply” and “just” which we now know is insensitive to people who may not find certain tasks easy. In addition, they also ran into one of the negatives of the linter which is false positives. In this case, it was flagging words like “color” and “special” which fall under the list of insensitive language however in this context it was not. Their takeaway from working with Alex was that their default way of writing will need some work that can be taken as insensitive and Alex is a tool that helps them in making their work more inclusive.

After reading Suzanne Aitchison’s blog, I found the reading very helpful because it further pushed me in the right direction of working with more inclusive language as well as pointing out things that I did not catch when we were working on our exclusivity activity in class. I feel like as we progress as a society and we are working on becoming more inclusive tools like Alex JS will be very helpful. When we first started the in class activity I didn’t see a problem with some of the flagged words however after seeing why they were being flagged as well as reading the blog I am increasingly understanding how certain words can be taken from those that come from other backgrounds than I do. My main takeaway from this will be working on using more inclusive language and making sure that my work can be taken in a positive note from whoever reads it.

https://dev.to/s_aitchison/refactoring-condescending-language-with-alexjs-3ifp

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

Writing clean code: A developers guide to readable and maintainable code

Clean code refers to computer code that is easy to read, comprehend, and maintain. This type of code is crafted to be straightforward, concise, and expressive, following specific conventions, standards, and practices that enhance readability and clarity. 

The importance of clean code cannot be overstated. When code is readable and comprehensible, it facilitates collaboration among developers and boosts productivity while minimizing errors. Additionally, easy maintainability is crucial for long term projects, ensuring that the codebase can be updated and enhanced over extended periods. The foundation of clean code lies in its readability and maintainability, as beautifully articulated in the blog “How to write clean code?” By FreeCodeCamp. In this article, we’ll dissect the principles and practices behind clean code, and give you a few tips on how to craft clean cod.

Assessing Code Cleanliness

Determining whether code meets the standards of cleanliness involves various aspects. Good documentation, consistent formatting, and a well-organized codebase serve as benchmarks for clean code. Additionally, code reviews and thorough testing contribute to identifying potential issues and ensuring adherence to best practices.

By incorporating tools, practices, and conventions, developers can create a codebase that is efficient.

Tips for writing clean code:

  1. Effectiveness, Efficiency, and Simplicity
    • Prioritize effectiveness to ensure the code solves the intended problem.
    • Strive for efficiency by optimizing resource usage.
    • Embrace simplicity for code clarity and easy comprehension.
  2. Format and Syntax
    • Enforce consistent indentation and spacing.
    • Maintain a uniform syntax throughout the codebase.
    • Adhere to consistent case conventions (camelCase, PascalCase, snake_case).
  3. Naming
    • Choose clear and descriptive names for variables and functions.
    • Avoid vague or generic names that obscure the purpose of the entity.
  4. Conciseness vs. Clarity
    • Strike a balance between concise and clear code.
    • Prioritize clarity to enhance readability, even if it means sacrificing conciseness.
  5. Reusability
    • Design code with reusability in mind, promoting efficiency in development.
    • Embrace modular and scalable software architectures.
  6. Clear Flow of Execution
    • Ensure a logical and clear flow of execution in the code.
    • Steer clear of spaghetti code through thoughtful organization and structure.
  7. Single Responsibility Principle (SRP)
    • Assign a single responsibility to each class or module.
    • Enhance code readability and maintainability by adhering to SRP.
  8. Single Source of Truth
    • Centralize data or configurations to avoid duplication and ensure consistency.
    • Simplify updates by having a single source for critical information.
  9. Only Expose and Consume Needed Data
    • Minimize exposure or consumption of unnecessary information.
    • Utilize object destructuring for selective access to required data.
  10. Modularization
    • Break down code into smaller, manageable modules for ease of understanding.
    • Foster reusability and maintainability through thoughtful modularization.
  11. Folder Structures
    • Organize the project based on features rather than file types.
    • Cultivate a clear and logical folder structure for seamless navigation.
  12. Documentation
    • Employ comments to provide context and explain the functionality of the code.

Reference: https://www.freecodecamp.org/news/how-to-write-clean-code/

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

Blog #4: Disadvantages of Agile

Fundamentally Agile is a very flexible and effective methodology that allows teams to continuously provide a working model of their respective project. When compared to the Waterfall methodology, Agile may seem like a flawless approach to team development and management, however this comparison to Waterfall fails to capture Agile’s flaws. Ideally, by understanding Agile’s feats and flaws, teams can make the most of the methodology.

Agile works best when all members deliver their respective parts of the project on time. This creates pressure on the developers to reach that time quota, as a result they may be more inclined to ‘cut corners’ so to speak while developing their part. Creating faulty code (or a general product) may lead to future issues, which would likely lead to sprint backlog bloat, so the development methodology must balance the value of the work being created and the time being spent to create the aforementioned work.

On the topic of time management, Agile does not offer much flexibility while creating sprints. Sprint length is determined towards the beginning of development, this itself is an issue as developers lack the foresight to allocate enough time in a sprint to take on larger-scale projects. Sprints encourage segments of digestible work for the developer, as Bryar and Carr mention in the article Have We Taken Agile Too Far?, “rather than take the time and uncertainty to develop a new capability, they go with the skills they currently have” (Bryar & Carr). Due to time constraints, developers settle with what they’re most comfortable with, as opposed to seeking potentially more effective solutions. This damages the final product as it heavily depends on the developers’ current experience and does not promote research.

One solution to this issue would be shifting to the Epic-model. Here developers won’t face an imminent time constraint that sprints impose, rather they will take a task (a story) and aim to complete it before the team moves on to the next step (the epic). This type of work structuring does not intrinsically have a set time limit but can be integrated within the Agile methodology. The goal of combining these two types of work structuring is to create a process where developers can have assigned tasks that are components of a larger task, AND to have a flexible time limit before moving on to the ‘larger task’. Another solution would be to fundamentally change how Agile works within a team. Currently, there are very few exceptions to change the duration of a sprint period, so to shift to a variable duration of each sprint would change how Agile works. A downside of doing this would be removing the consistency between sprints, but the benefit of that is that developers may be able to take on more work or do more research into their respective tasks before delivering their first working model. As a development methodology Agile should benefit the developers, therefore shifting from a rigid (preset) working period may increase the quality of work.

-AG

Source:

https://hbr.org/2021/04/have-we-taken-agile-too-far

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

Blog #3: Kanban Expanded

While attending my previous university, Becker College, I was introduced to Scrum, Agile, and Kanban with very surface-level information. As we progressed through this current semester, my knowledge of both Scrum and Agile increased, with my knowledge of Kanban tailing behind. So I seek to answer the question of ‘What is Kanban’?

Kanban, similar to Scrum, is a type of work structuring that places importance on visual responsiveness and flexibility. Scrum and Agile run on the idea of sprints, which Kanban does not naturally have, but rather it opts to focus on a time cycle. Time cycles measure how long it will take a single task to move through all stages of development. A potential flaw here would be that if the team agrees upon many stages of development, such as adding multiple testing stages, then the average time cycle will take longer. By not imposing a static time limit, such as those provided by Sprint structuring, it encourages developers to put as much effort as possible into their respective task(s). The key to an efficient team would be to optimize these time cycles and get their average down to shorter periods while maintaining the quality of work.

Within the development process, each task is represented by a card and will move through the Kanban board as it advances in the development cycle. This board helps create the visual responsiveness that Scrum lacks. If a card is stuck in one phase of development, then fellow developers may take notice and help push it to the next stage. While visual responsiveness does help to grant a sense of worth seeing tasks being completed, it best serves as a collaborative tool between developers which further increases team efficiency.

Kanban would be my preferred choice of work structuring as I find that the Kanban board is an incredibly useful tool to both track and collaborate with your team. However, one glaring issue I do have with Kanban is the lack of a direct CD (continuous delivery). Scrum will have the Sprint Review and Retrospective which gives the development team a chance to show their current working model of the project and get suggestions for it. Kanban lacks this dedicated period to show the project and communicate with their partner. This runs the risk of high-effort work being rendered useless as it’s not what their business partner had in mind. Additionally, with the lack of a Retrospective, the team will not have a dedicated period to reflect on their progress and comment on places they may optimize their work. A solution here would be to create sprint-like periods where no work is due, but at the end of the period, developers will have both a review session with their business partner and a retrospective within the team. This increase in general communication will ensure the product will be created effectively and will meet all requested specifications.

-AG

Source:

https://www.atlassian.com/agile/kanban#:~:text=What%20is%20kanban%3F,of%20work%20at%20any%20time.

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.