Special

Introducing the “Welcome to Xojo” Bundle!

New to Xojo and looking for guidance? We've put together a terrific bundle to welcome you! Xojo Bundle

This bundle includes six back issues of the magazine -- all of year 21 in printed book and digital formats -- plus a one-year subscription (beginning with 22.1) so you'll be learning all about Xojo for the next year. It's the perfect way to get started programming with Xojo. And you save as much as $35 over the non-bundle price!

This offer is only available for a limited time as supplies are limited, so hurry today and order this special bundle before the offer goes away!

Article Preview


Buy Now

Issue 22.4 ('Spy On Your Variables')
Instant purchase and download via GumRoad!

FEATURE

Comments on Comments

Tim Dietrich discusses the role of comments in his development process, the importance of comments to him, and some different opinions on the topic.

Issue: 22.4 (July/August 2024)
Author: Tim Dietrich
Author Bio: Tim uses Xojo to develop custom software for businesses that are running on NetSuite.
Article Description: No description available.
Article Length (in bytes): 7,457
Starting Page Number: 38
Article Number: 22405
Related Link(s): None

Excerpt of article text...

Over the course of my career, I've had opportunities to work on projects that involved a number of different programming languages, including Pascal, Clarion, Perl, FileMaker, BroadVision, SQL, PL/SQL, T-SQL, JavaScript, Xojo, Swift, and more recently, SuiteScript (NetSuite's JavaScript-based language). But the one constant in all of my development work has been how I use comments, and how important they are to me.

I was thinking about this recently, and realized that I can trace my use of comments back to my college days. When working on a programming assignment, I'd start by essentially outlining the code, and I'd use comments as a sort of "meta code" to build the outline. The outline would start off in a very basic form, and I'd gradually add details.

I'd eventually use the comments to help me write the "real code." I'd move blocks of code around, identify common code that might be best implemented as functions or procedures, and so on. As a result of this process, the solution would emerge. In fact, this is the same approach that I use today.

In most cases, I'll leave the comments in place. My reason for doing this is that I figure I've already written the comments, and there's generally no harm in retaining them. I often find that those comments are helpful when I need to work on code that I've written awhile ago. They've also been helpful in cases where the code was assigned to another developer—regardless of whether the other developer was "junior" or not.

For me, commenting code is a natural part of my development process. And again, I've found comments to be invaluable. I think that's why I'm so surprised when I talk to other developers, or read articles and comments (no pun intended) online, where comments are seen in such a drastically different way.

"Good Code Documents Itself"

...End of Excerpt. Please purchase the magazine to read the full article.