Comments on: What’s your level of code assertions? http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/ Web development and Internet trends Tue, 06 Jan 2009 11:08:16 +0000 http://wordpress.org/?v=2.6.1 By: Summer break - Robert’s talk - Web development and Internet trends http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-301965 Summer break - Robert’s talk - Web development and Internet trends Thu, 12 Jun 2008 23:18:00 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-301965 [...] What’s your level of code assertions? [...] [...] What’s your level of code assertions? [...]

]]> By: DOMAssistant 2.5.6 released - AJAX module post method has been fixed - Robert’s talk - Web development and Internet trends http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-184804 DOMAssistant 2.5.6 released - AJAX module post method has been fixed - Robert’s talk - Web development and Internet trends Mon, 14 Jan 2008 08:19:35 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-184804 [...] stripped the URL in AJAX GET requests as well. Something I knew, but that’s what I get for preaching about assertions but not applying it properly to my own code. I guess my intuition took overhand for a [...] [...] stripped the URL in AJAX GET requests as well. Something I knew, but that’s what I get for preaching about assertions but not applying it properly to my own code. I guess my intuition took overhand for a [...]

]]> By: Robert Nyman http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-180363 Robert Nyman Wed, 09 Jan 2008 12:59:42 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-180363 Jakob, Absolutely, JsUnit is a good advice! Mikael, Yes, I think I use the "savage" approach from time to time as well. You just want to test the concept, and eventually, in the second or third stage, the code actually gets good. But I guess this is one of the reason why agile development has become so popular. You want to try things out for a while, and then you're absolutely open to change your first impression, since you learned a number of things along the path. Jakob,

Absolutely, JsUnit is a good advice!

Mikael,

Yes, I think I use the “savage” approach from time to time as well. You just want to test the concept, and eventually, in the second or third stage, the code actually gets good.

But I guess this is one of the reason why agile development has become so popular. You want to try things out for a while, and then you’re absolutely open to change your first impression, since you learned a number of things along the path.

]]> By: Mikael Bergkvist http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-180317 Mikael Bergkvist Wed, 09 Jan 2008 11:40:54 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-180317 I'm one of those coders that write the code until it just works regardless if it's *good* or *bad*, like a savage, sometimes (mostly) it's just horrible, and then I usually wait a while and then go back, fixing the stuff that's lazy, overly complicated, repeative or just plain wierd. Mostly there are no assertions in the code at this stage. Often I realise during the second stage, that the code I had written is nothing short of really horrible, and that it was probably just a lucky accident that it worked to begin with. The first go-round is like a sketch for me, I'm just looking for it to do something that I want. Then - after a while - I go back to the horror that is my coding, and essentially spend time doing nothing but 'saving it' back to something that's not completely offensive to the human mind. I've tried to change my ways, but I always fall back into this procedure nomatter what I do. However, this particular issue is one of those 'things' that always pop up somewhere during that second phase of rewriting. Thanks for posting about it. I’m one of those coders that write the code until it just works regardless if it’s *good* or *bad*, like a savage, sometimes (mostly) it’s just horrible, and then I usually wait a while and then go back, fixing the stuff that’s lazy, overly complicated, repeative or just plain wierd.
Mostly there are no assertions in the code at this stage.
Often I realise during the second stage, that the code I had written is nothing short of really horrible, and that it was probably just a lucky accident that it worked to begin with.
The first go-round is like a sketch for me, I’m just looking for it to do something that I want.
Then - after a while - I go back to the horror that is my coding, and essentially spend time doing nothing but ’saving it’ back to something that’s not completely offensive to the human mind.
I’ve tried to change my ways, but I always fall back into this procedure nomatter what I do.
However, this particular issue is one of those ‘things’ that always POP up somewhere during that second phase of rewriting.
Thanks for posting about it.

]]> By: Jakob Heuser http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-179589 Jakob Heuser Tue, 08 Jan 2008 17:13:24 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-179589 Assertions are at the core of unit testing. There's nothing quite as satisfying as writing your expected behavior, then writing the code itself. JS has finally reached a point where it's testing frameworks are maturing properly. http://www.jsunit.net/ is one of the more prominent ones, and I believe YUI has also fleshed out their testing framework in the most recent version. Assertions are at the core of unit testing. There’s nothing quite as satisfying as writing your expected behavior, then writing the code itself.

JS has finally reached a point where it’s testing frameworks are maturing properly. http://www.jsunit.net/ is one of the more prominent ones, and I believe YUI has also fleshed out their testing framework in the most recent version.

]]> By: Robert Nyman http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-179549 Robert Nyman Tue, 08 Jan 2008 15:58:08 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-179549 Brian, Thank you! I agree, to a certain extent. There re certain scenarios where assertions is just a given; not having them there wouldn't be doing your job properly. But there's definitely other cases where you want the code to fail, to know what assertions to apply accordingly. I like to stress test my code to know when things hit the brick wall, so I can make sure it won't when being deployed live. Brian,

Thank you!
I agree, to a certain extent. There re certain scenarios where assertions is just a given; not having them there wouldn’t be doing your job properly.

But there’s definitely other cases where you want the code to fail, to know what assertions to apply accordingly. I like to stress test my code to know when things hit the brick wall, so I can make sure it won’t when being deployed live.

]]> By: Brian Reindel http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-179527 Brian Reindel Tue, 08 Jan 2008 15:26:27 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-179527 Hey Robert, This was a great read, and a post that can be easily understood by all levels of JavaScript programmers. My only suggestion would be: do not begin with assertions, but be sure that your production-ready code contains assertions. The only reason I mention this, is that often I want to know when something went wrong, when it should not. Getting an "object undefined" error can be a helpful tool in debugging your scripts. However, if you do object detection from the get-go, nothing happens. The same is true with try/catch -- IMHO these should be used as "I might have forgot a use-case scenario insurance policy" on a live site. Again, great post. Hey Robert,

This was a great read, and a post that can be easily understood by all levels of JavaScript programmers.

My only suggestion would be: do not begin with assertions, but be sure that your production-ready code contains assertions. The only reason I mention this, is that often I want to know when something went wrong, when it should not. Getting an “object undefined” error can be a helpful tool in debugging your scripts. However, if you do object detection from the get-go, nothing happens. The same is true with try/catch — IMHO these should be used as “I might have forgot a use-case scenario insurance policy” on a live site.

Again, great post.

]]> By: Robert Nyman http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-179347 Robert Nyman Tue, 08 Jan 2008 11:48:49 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-179347 Anders, Sounds like a great idea! I'm very impulsive myself, but there are times where I wish i would have sat down and thought things through properly first. I think very few people are experts, but I hope that I reach a level of Proficient myself within certain areas Morgan, Thanks for the tip about FailFast! Steven, Yes, good semantic names in the code is always something to strive for. And <code>try...catch</code> definitely has its place, but it usually tends to get overused. Steven, Cory, I'd say that helpful comments in the code within the right context can help other developers. However, unit tests are of course also a great way to learn. Anders,

Sounds like a great idea! I’m very impulsive myself, but there are times where I wish i would have sat down and thought things through properly first.

I think very few people are experts, but I hope that I reach a level of Proficient myself within certain areas

Morgan,

Thanks for the tip about FailFast!

Steven,

Yes, good semantic names in the code is always something to strive for. And try...catch definitely has its place, but it usually tends to get overused.

Steven, Cory,

I’d say that helpful comments in the code within the right context can help other developers. However, unit tests are of course also a great way to learn.

]]> By: Steven Clark http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-179005 Steven Clark Tue, 08 Jan 2008 04:43:10 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-179005 Cory are you referring to the function inputs and outputs making it into your internal documentation (comment above the function block)? Your unit tests may show those conditions work. But someone scanning your code or having to make modifications will get a lot out of simply seeing what is expected as input and as output. They address a different need than unit testing. By writing the inputs and outputs in there you have an internal documented record of what that function takes and returns. I hope that explains better what I meant in my comment. Cory are you referring to the function inputs and outputs making it into your internal documentation (comment above the function block)?

Your unit tests may show those conditions work. But someone scanning your code or having to make modifications will get a lot out of simply seeing what is expected as input and as output. They address a different need than unit testing.

By writing the inputs and outputs in there you have an internal documented record of what that function takes and returns.

I hope that explains better what I meant in my comment.

]]> By: Cory Foy http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-178929 Cory Foy Tue, 08 Jan 2008 03:01:08 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-178929 Steven - why wouldn't you just write /unit tests/ to make sure those conditions are working? Even JavaScript has JSUnit. Steven - why wouldn’t you just write /unit tests/ to make sure those conditions are working? Even JavaScript has JSUnit.

]]> By: » Blog Archive » Use Comment Blocks Before Your Functions - StevenClark.com.au http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-178769 » Blog Archive » Use Comment Blocks Before Your Functions - StevenClark.com.au Mon, 07 Jan 2008 23:43:36 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-178769 [...] these aren’t the tips I’m thinking of this morning. Robert Nyman’s post on code assertions got me thinking about writing maintainable functions. I’d like to bring your attention to the [...] [...] these aren’t the tips I’m thinking of this morning. Robert Nyman’s post on code assertions got me thinking about writing maintainable functions. I’d like to bring your attention to the [...]

]]> By: Steven Clark http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-178726 Steven Clark Mon, 07 Jan 2008 22:58:20 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-178726 Another really good habit to get into when writing functions - comment above the function of the expected inputs and outputs. This can save a lot of time when the next person comes along to maintain your code. And meaningful names rather than variables like e, n or fp can go a long way to improving readability, and therefore maintainability. Sorry, maybe that was slightly off topic. I agree with your example in JavaScript re: try catch phrases for the purpose you've described but they have their place. I am not very strong in JavaScript though so my programming experience is not browser based. I've just read 2 Jeremy Keith books as I've finally picked up JavaScript and assertions seem the natural best practice. Robust quality code is an objective that should always be a priority. Another really good habit to get into when writing functions - comment above the function of the expected inputs and outputs. This can save a lot of time when the next person comes along to maintain your code.

And meaningful names rather than variables like e, n or fp can go a long way to improving readability, and therefore maintainability.

Sorry, maybe that was slightly off topic.

I agree with your example in JavaScript re: try catch phrases for the purpose you’ve described but they have their place. I am not very strong in JavaScript though so my programming experience is not browser based.

I’ve just read 2 Jeremy Keith books as I’ve finally picked up JavaScript and assertions seem the natural best practice. Robust quality code is an objective that should always be a priority.

]]> By: Morgan Roderick http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-178460 Morgan Roderick Mon, 07 Jan 2008 17:57:53 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-178460 I am using assertions more and more, across many technologies. For javscript / dom, I've been using assertions for a looong time ... not wanting to throw exceptions in the face of users. Recently, in my day job, I've taken up FailFast (<a href="http://martinfowler.com/ieeeSoftware/failFast.pdf" rel="nofollow">http://martinfowler.com/ieeeSoftware/failFast.pdf</a>) and am having a great time, building more robust code, that blows up in my face early, instead of when it reaches the production environment. How <em>you</em> implement FailFast, or use assertions, I leave up to youl. But, it's certainly made my life a little easier :-) I am using assertions more and more, across many technologies.

For javscript / DOM, I’ve been using assertions for a looong time … not wanting to throw exceptions in the face of users.

Recently, in my day job, I’ve taken up FailFast (http://martinfowler.com/ieeeSoftware/failFast.pdf) and am having a great time, building more robust code, that blows up in my face early, instead of when it reaches the production environment.

How you implement FailFast, or use assertions, I leave up to youl. But, it’s certainly made my life a little easier :-)

]]> By: Anders Ytterström http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-178426 Anders Ytterström Mon, 07 Jan 2008 17:18:42 +0000 http://www.robertnyman.com/2008/01/07/whats-your-level-of-code-assertions/#comment-178426 I do my very best to use assertions. Now and then I catch my self over analyzing the code I currently work on. Because of that, I usually spend more time with pen and paper before even creating the files. This helps me to at least find 8 of 10 assertions which otherwise should have breaking my creative flow. When it comes to javascript, Jeremy Keith's "Dom Scripting" got me interested in the first place. That book really emphasize the need of never taking anything for granted. IMHO, I place myself somewhere at <strong>Proficient</strong>, since I am not completely self going get. I do my very best to use assertions. Now and then I catch my self over analyzing the code I currently work on. Because of that, I usually spend more time with pen and paper before even creating the files. This helps me to at least find 8 of 10 assertions which otherwise should have breaking my creative flow.

When it comes to javascript, Jeremy Keith’s “DOM Scripting” got me interested in the first place. That book really emphasize the need of never taking anything for granted.

IMHO, I place myself somewhere at Proficient, since I am not completely self going get.

]]>