The Debate on Comments in Code | 8min snip from Ruby for All

Get the app

From CoffeeScript to curl

Ruby for All

chevron_right

notes

CHAPTER

The Debate on Comments in Code

The speakers discuss their views on comments in code, highlighting the benefits and drawbacks. They also mention alternative ways of documenting code and briefly discuss their current tasks.

00:00

Transcript

chevron_right

Play full episode

chevron_right

Transcript

Episode notes

In this episode of Ruby for All, we start with a conversation about Julie’s challenges in adjusting to a calendar migration, which leads to discussions about productivity tools, color-coding calendars, and the use of extensions like “Better Comments” for code organization. Andrew and Julie explore the purpose and potential pitfalls of code comments, share insights into work projects, including a significant rewrite, and even touch on the history of CoffeeScript in the coding world. Also, they discuss best practices for API response statuses, the effective use of tools like Postman and curl, and the role of practical experience in shaping a developer’s understanding of best practices. Hit download now to hear more!

[00:00:10] Julie mentions having issues concentrating at work due to a migration from Google Workspaces to Microsoft, with calendar issues. Andrew asks about her calendar system and whether she color codes it.

[00:01:41] Since colors are so important to Andrew on calendars, he mentions an extension called “Better Comments” for color-coding comments in code.

[00:03:15] Andrew discusses the purpose of comments, warning about deviations from conventions, and code readability, and Julie and Andrew talk about the problems with excessive comments and the importance of keeping comments up to date.

[00:07:08] Julie wonders if Andrew adds links to comments or writes detailed PR reviews for reference.

[00:07:53] What’s up with Andrew? He mentions working on bug fixes and a recent launch at Podia, including a rewrite of their email system.

[00:08:51] Andrew explains Trix, which was previously written in CoffeeScript but may have been ported to TypeScript. He also briefly discusses the history of CoffeeScript, its decline in popularity, and why he didn’t like it when he was new to programming.

[00:13:21] Julie asks about best practices for API response statuses, such as when to use “status ok” or “status created.” She also asks about the use of “Unprocessable Entity” as a status code and its meaning. Andrew talks about how Rails handles different response statuses and mentions that Rails implicitly handles certain errors.

[00:15:58] Julie and Andrew discuss the importance of choosing the correct HTTP status codes for API responses.

[00:16:44] Julie asks about handling different types of bad requests and whether Rails catches them. Andrew explains how to undo scaffolded code using “rails d” and suggests looking at Rails scaffold defaults for best practices.

[00:18:50] Andrew explains what Postman is and describes it as an interface for sending API requests. He also talks about the VS extension code, Thunder Client.

[00:20:26] Andrew explains the benefits of using curl and jq for API requests and JSON processing.

[00:21:14] We hear an example of using curl and jq to retrieve specific data from a GitHub API endpoint.

[00:22:15] Julie mentions using ChatGPT as a “rubber duck” to find answers to coding questions and appreciates how it exposes her to new concepts.

[00:22:43] Andrew and Julie discuss the importance of focusing on a way to solve problems, especially for early career developers, rather than getting caught up in finding the “right” way.

[00:24:26] Julie brings up Ruby for All Episode 46 that you should check out, where they discussed Single Tab Inheritance (STI).

Panelists:

Andrew Mason

Julie J.

Sponsor:

Links: