On CBS.com: No Line On The Horizon by U2

Assist future developers by writing comments and clean code

Tags: Scripting languages, line comment, Tony Patton, JavaScript, developer, Web Development Zone Newsletter

  • Save
  • Print
  • Recommend
  • 1

Takeaway: Tony Patton explains that thoroughly documenting your code either through written documents or code comments helps you and provides future guidance for developers working with the code.

I have preached about documenting code countless times with fellow developers, but I recently unearthed a strange fact: Many developers don't consider JavaScript or HTML coding, so they rarely document such code. Thoroughly documenting your JavaScript code either through written documents or code comments not only helps you, but it also provides future guidance for developers working with the code.

Document your code with comments

Written documentation is good, but I still like to include documentation in the actual code—just in case the written documents cannot be found. Documenting your code is also good practice, and it is easy to do on-the-fly as you are coding. Some languages like Java and C# provide special documentation features.

JavaScript does not include such features, but you can easily include documentation with comments. There are two ways to include a comment in JavaScript:

  • The /* (start comment) and */ (stop comment) character combinations allow you to include multi-line comments, so everything between the start and stop comment indicators is not executed.
  • A single line comment is created with two backslash characters (//). Any text after the two backslashes is ignored. These comments may exist on their own line or at the end of a line of JavaScript.

The HTML sample in Listing A includes JavaScript that demonstrates the use of both techniques. It is a simple HTML page that displays a message box when the page is loaded, but it includes plenty of documentation. You may prefer developing the next cool trick, but some of this time can be devoted to documenting your code. After all, great code does not necessarily innovate, but implements in a clean and accessible manner and keeps maintenance easy.

Weekly development tips in your inbox
Keep your developer skills sharp by signing up for TechRepublic's free Web Development Zone newsletter, delivered each Tuesday.
Automatically sign up today!

There is a point where you can include too much information when documenting your code. After all, each and every line of code does not require documentation. Here are a few guidelines for documenting your JavaScript:

  • Document all functions including their purpose along with description of its parameters and return value (if it exists). My simple example includes such information. I like to include the author and date, but you can choose to include this in the page documentation (since it's probably the same for the entire page), but that is the developer's and organization's preference.
  • Document any obscure or complex code to help future developers understand what it is doing.
  • Code changes should include a line detailing the change, as well as who made it and why. This can aid debugging and in tracking down developers.

These guidelines are not stringent and may vary among organizations; the key is to be consistent so all code follows a set approach.

Write clean code

Documenting your code is just one aspect of easing code maintenance. Another way you can help fellow developers is by keeping your code readable through the following additional techniques:

  • Proper indentation
  • Self-explanatory variable and method names
  • Consistent bracket placement for script blocks

While the specifics of code-display within the TechRepublic.com site negates indentation in the sample code in this article, you should indent your code according to developer and/or organization preference. Also, you will notice the variable and function names in the example are rather self-explanatory, so a developer could ascertain code functionality without accompanying comments.

The last item on the list is related to the placement of braces ({ and }) that enclose code blocks. I've worked with organizations that prefer the opening bracket on its own line and others where the first bracket is on the end of the first line of code in the block. The sample code uses the former approach, but the function could easily use the other technique as demonstrated by the code in Listing B.

HTML comments

In addition to JavaScript comments, you can include comments or documentation in HTML with HTML formatted comments. HTML comments use the following formatting:

<!-- This is an HTML comment -->

The sample code includes an HTML comment at the top of the page. Comment placement depends upon the project, but they can easily be used to omit portions of the page from loading/execution to assist with debugging.

Helping others

Developing readable code is a continual process that you should follow on a daily basis. After all, documentation is abhorred by most developers, so going back and documenting code after a project is complete is not on anybody's wish list. You can include comments and consistently format your code to assist future developers charged with maintenance or changes.

Miss a column?

Check out the Web Development Zone archive, and catch up on the most recent editions of Tony Patton's column.

Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.

  • Save
  • Print
  • Recommend
  • 1

Print/View all Posts Comments on this article

Thanks for writing this and a pointer dmuth | 10/17/06
Total rubbish Tony Hopkinson | 10/17/06
Not total rubbish steve@... | 10/19/06
Well you certainly had to comment machine code! Tony Hopkinson | 10/19/06
Documentation!? deepsand | 10/27/06
Bah...Real coders write everything in obfuscated perl in one line... jmgarvin | 10/27/06
Obfuscated Perl.... beowulf_cam | 11/11/06
Couldn't agree more I'm still trying to figure out Tony Hopkinson | 10/28/06
In my experience, documentation goes first. deepsand | 10/28/06
Comments to explain why, not how RexWorld | 10/19/06
I can live with some of that Tony Hopkinson | 10/19/06
WOW, Do I disagree with you JohnBoehlke | 10/19/06
Considered ? Tony Hopkinson | 10/19/06
Confidence? Ken Cox | 10/20/06
Hopefully the developer will... Tony Hopkinson | 10/20/06
Not total rubish Tony, Jaqui | 10/20/06
Well it was a bit strong but Tony Hopkinson | 10/20/06
oh yeah, Jaqui | 10/21/06
Why as well as what grantwparks | 10/20/06
Someone else raised that point and I agree Tony Hopkinson | 10/20/06
Half and Half marketingtutor. | 10/23/06
Comments depend on the coder as well Tony Hopkinson | 10/24/06
I totally agree marketingtutor. | 10/24/06
That will be interesting Tony Hopkinson | 10/25/06
Comments or No Comments stew@... | 10/24/06
I can live with all that as well Tony Hopkinson | 10/24/06
I suggest you read jmgarvin | 10/25/06
Thanks - I'll read that Tony Hopkinson | 10/25/06
True... jmgarvin | 10/25/06
Oh I'll take a good idea from anywhere Tony Hopkinson | 10/26/06
utter crap GrizzledGeezer | 11/10/06
Well, if you read the rest of Tony's posts here, ... deepsand | 11/11/06
Agree to Disagree Ken Cox | 10/18/06
Try a Version Control System Instead Wayne M. | 10/18/06
If you have issue tracking and you attach the ID Tony Hopkinson | 10/18/06
I'm happy to debate the issue. Tony Hopkinson | 10/18/06
Agreed that there is no perfect method out there Ken Cox | 10/19/06
Total agreement Tony Hopkinson | 10/19/06
Some Languages Yes - Others No Norman.Paden@... | 10/19/06
That's not so much language Jaqui | 10/20/06
Comments are needed! erickschluter@... | 10/19/06
The personal touch Tony Hopkinson | 10/19/06
You may have just explained why I comment so much DanLM | 10/20/06
Specially in CSS Jaqui | 10/20/06
Group comments are good in css marketingtutor. | 10/23/06
that is Jaqui | 10/24/06
Of course comments are needed... DonDNH@... | 10/19/06
The requirements Tony Hopkinson | 10/19/06
Everyone thinks they write clean code meceli@... | 10/19/06
readable code Tony Hopkinson | 10/19/06
Can't agree more bgersekowski@... | 10/19/06
Agree that the "need" to heavily comment might indicate grantwparks | 10/20/06
Typing Comment Characters Does Not Make Me A Better Writer Wayne M. | 10/20/06
Agree wit the need for comments wamorita@... | 10/19/06
Bad comments are about Tony Hopkinson | 10/19/06
Bad comments are WORSE than having none bgersekowski@... | 10/19/06
i don't believe in karma mac1ne | 10/19/06
Thank you, I was feeling outnumbered Tony Hopkinson | 10/19/06
You are not alone... bgersekowski@... | 10/19/06
Well Wayne has been weighing in Tony Hopkinson | 10/19/06
Comments != Documentation SnoopDoug | 10/19/06
Why not both? Here's why? bgersekowski@... | 10/19/06
Here!,Here!... murdo@... | 10/19/06
Fair go Tony Hopkinson | 10/19/06
Ok, I freely admit. I most likely go to the comment extreme DanLM | 10/19/06
I use work in progress comments a lot Tony Hopkinson | 10/19/06
Spaghetti Design ProblemSolverSolutionSeeker | 10/20/06
See Refactoring and Evolutionary Design Wayne M. | 10/20/06
I always liked the broken window analogy Tony Hopkinson | 10/20/06
Commenting hobby.harold@... | 10/20/06
I know another Tony Hopkinson | 10/20/06
Interesting... bgersekowski@... | 10/21/06
I'm still not getting the in the eye of the beholder bit Tony Hopkinson | 10/21/06
Documenting Code the56thjunker@... | 10/23/06
You should have read the other comments ! Tony Hopkinson | 10/23/06
Tony, your examples of variable names is what I mean DanLM | 10/24/06
well you can go mad Tony Hopkinson | 10/25/06
Comments on Comments Wayne M. | 10/31/06
Methods? Classes? Name implied purposes? deepsand | 10/31/06
Comments are absolutely necessary JEfromCanada | 12/08/06
Good recommendations, one nitpick bbloom@... | 10/17/06
They don't comment NOW LEFT TR | 10/17/06
Better code does not need comments myrdhrin | 10/17/06
Comments show INTENT bschaettle@... | 10/17/06
So you change your code twice? myrdhrin | 10/17/06
No, you change three areas SnoopDoug | 10/19/06
So was the comment correct? Tony Hopkinson | 10/17/06
Comments state business logic intent Ken Cox | 10/17/06
Intent. Tony Hopkinson | 10/17/06
How Many of you have Inherited someone else's code? Hendry_Betts | 10/17/06
Well lots of us actually Tony Hopkinson | 10/17/06
Rocket Science it ain't Hendry_Betts | 10/18/06
oops Tony Hopkinson | 10/18/06
But there are comments and there are comments bgersekowski@... | 10/19/06
Use the Method Name to Define the Return Wayne M. | 10/18/06
WTF? deepsand | 10/27/06
Assist future developers by writing clean code, not comments Wayne M. | 10/17/06
Eggsactly Tony Hopkinson | 10/17/06
What about the process ? oisleach@... | 10/19/06
A different way of working Tony Hopkinson | 10/19/06
You're not thinking of the bigger picture bgersekowski@... | 10/19/06
Methods that do more than one 'thing' Tony Hopkinson | 10/19/06
Great example Jaqui | 10/20/06
Well the purist in me Tony Hopkinson | 10/20/06
guarantee no data change? Jaqui | 10/22/06
Well the locking is optimistic. Tony Hopkinson | 10/22/06
clean code doesn't need documentation sepahram | 10/18/06
Obscure and complex code Tony Hopkinson | 10/18/06
Good point sepahram | 10/22/06
I don't believe in complex code Tony Hopkinson | 10/23/06
Live in the real world for a while ... DPitz | 10/19/06
Put All Data Constraints In Code Wayne M. | 10/19/06
Are you enforcing the Tony Hopkinson | 10/19/06
Obvious is in the eye of the beholder JimmyF | 10/19/06
Hmm you've probably just highlighted the Tony Hopkinson | 10/19/06
Most languages are NOT, & most programs CANNOT be, self-documenting. deepsand | 10/23/06
And Your Rationale is? Wayne M. | 10/23/06
Of non-standard libraries, assembly languages, etal. deepsand | 10/23/06
The Advantage of Commented Library Calls? Wayne M. | 10/24/06
Library functions may be content neutral deepsand | 10/24/06
May Have to Disagree on Performance Degradation Wayne M. | 10/26/06
In a perfect world, ... deepsand | 10/27/06
The Difficulties with Assembly Languages Are? Wayne M. | 10/24/06
Assigning names to hardware features does not solve the problem. deepsand | 10/24/06
Is This Self-Documenting? Wayne M. | 10/26/06
It would be; but ... deepsand | 10/27/06
Then Is This Self Documenting? Wayne M. | 10/30/06
Because POP is content neutral. deepsand | 10/31/06
Personally I'd be extremely worried if Tony Hopkinson | 10/25/06
Precisely my point. deepsand | 10/28/06
Ignore this post; it was misplaced. deepsand | 10/25/06
Most languages can be self documenting Tony Hopkinson | 10/23/06
"Most" vs. "most used by those here present" deepsand | 10/23/06
Self documenting assembler Tony Hopkinson | 10/24/06
Concur deepsand | 10/24/06
terribly missing the point mblackston@... | 10/19/06
totally agree ricardol_limon@... | 10/19/06
I agree as well xmetal | 10/19/06
You could not be more wrong Tony Hopkinson | 10/19/06
But comments won't save you bgersekowski@... | 10/19/06
Have Maintained Old Code Bases Wayne M. | 10/20/06
What others mean by clean code I 've no idea. To me Tony Hopkinson | 10/19/06
wel Jaqui | 10/23/06
Well regex is cryptic but is it code ? Tony Hopkinson | 10/23/06
yup Jaqui | 10/23/06
Dunno Tony Hopkinson | 10/23/06
How about Tony Hopkinson | 10/19/06
Code should never change? deepsand | 10/23/06
I think he was saying the intent won't change. Tony Hopkinson | 10/23/06
In your example, I think he meant the former. deepsand | 10/27/06
Maybe Tony Hopkinson | 10/27/06
Personally, I don't care for either extreme. deepsand | 10/27/06
Some people also WAY over estimate the reabablility of their code jmgarvin | 10/27/06
I've never achieved fully self documenting code Tony Hopkinson | 10/28/06
Are all the "my code is perfectly understandable" guys here yet? deepsand | 10/28/06
self documenting code.... Jaqui | 10/30/06
And The Information To Be Documented Is? Wayne M. | 10/30/06
External Documentation Tony Hopkinson | 10/30/06
Wayne M, Jaqui | 10/30/06
Responding in New Branch Below Wayne M. | 10/31/06

What do you think?

White Papers, Webcasts, and Downloads

Article Categories

Security
Security Solutions, IT Locksmith
Networking and Communications
E-mail Administration NetNote, Cisco Routers and Switches
CIO and IT Management
Project Management, CIO Issues, Strategies that Scale
Desktops, Laptops & OS
Windows 2000 Professional, Microsoft Word, Microsoft Excel, Microsoft Access, Windows XP,
Data Management
Oracle, SQL Server
Servers
Windows NT, Linux NetNote, Windows Server 2003
Career Development
Geek Trivia
Software/Web Development
Web Development Zone, Visual Basic, .NET

SmartPlanet

advertisement
Click Here