Comments on: Uncle Jens’s Coding Tips

By: anon

anon — Fri, 09 Jan 2009 19:44:08 +0000

on the subject of never use tabs
i have no option to either dis/agree
and many people don’t seem to realize this
but the TABS that are mostly argued against
are bad, no, i don’t support spaces they are just as
bad as these TABS as they force your preference onto others
personally i like tabs 4 spaces wide
but my tabs are soft-tabs

they are handled by the editor and if yo set your soft0tabs to 8, i’ll
always see them in 4 spaces..

summary: for me
hard-tabs and spaces =(
soft-tans =)

By: Dmitry Chestnykh

Dmitry Chestnykh — Wed, 09 May 2007 20:04:04 +0000

One more thing about instance variables — it seems Xcode 3 will color-code them: http://developer.apple.com/leopard/overview/tools.html

By: Trygve Isaacson

Trygve Isaacson — Tue, 08 May 2007 18:16:49 +0000

Good suggestions, Jens. Some IDEs (like IntelliJ) actually look for "todo" etc. markers and give you a to-do list from them. There are logging packages modeled after log4j out there that I think are generally a better choice than writing your own logging macros. The key is that you should leave your logging statements in the code (formed in a way that avoids overhead of messages that aren't being logged), and be able to change the logging level without recompiling, ideally while the app is running, but at the very least by simply changing a config file and restarting the app. It definitely should not require installing a new build. I have more detailed thoughts in response here.

By: /dev/random :: links for 2007-05-07

/dev/random :: links for 2007-05-07 — Mon, 07 May 2007 23:20:21 +0000

[…] Uncle Jens’s Coding Tips the main person you’re writing comments for is yourself, six months in the future (tags: programming tips) […]

By: Yotam Gingold

Yotam Gingold — Mon, 07 May 2007 21:16:52 +0000

Some commentary:
- A Warn() function is useful apart from assert(). Assert is useful when things *must* be true or the code will definitely die. But something like Warn() (I call it expect()) is useful when you have a hunch about how something will work but it’s not necessarily catastrophic if it’s otherwise. The thought is something like: “I expect that points will always lie between this and that, but I’m not positive. If they don’t, I’m curious to know if this code will still work.”

- A friend one switched me on to a macro he called PAINT(). In every code branch (function, if statement, else statement, etc), he would put a PAINT() there. PAINT() was basically an empty macro, but it was something he could put a breakpoint on (or print out line, file for you non-debugger types). Then, when running the program, remove all the PAINT()’s you hit. The purpose of this is to mark those code-paths you’ve never actually run, which becomes *very* useful when looking for bugs or figuring out why some function that always worked is producing weird results—-look for any PAINT statements hiding inside it in some conditional.
A poor-man’s variation of PAINT() I’m in the habit of doing now is putting a comment “untested” or “tested” at the top of a function. When I write the function, I add the “untested” comment. If I poke at the function and run some test cases, I change it to “tested,” but I don’t change it unless I deliberately and specifically test it with various input. That is, writing some random method, sticking it in the code somewhere, and running the entire program doesn’t merit a “tested.”

- Finally, I would add a word about comment blocks. I’m in the habit now of adding a good description comment for every function I write. Something like: “Takes as parameter a contour ‘contour’ (list of 2d points) and a list of distances ‘distances’ (a float for each point). Returns a contour offset from ‘contour’ by ‘distances’ at each point in the form of a tuple of 2 lists: ( left offset points, right offset points ).” This has been really helpful for “research” because I’m often trying things that don’t work and need to re-use code. How quickly I forget what a function with a tasty-looking name took as parameters and returned!

By: Hybrid simulation working group » Blog Archive » Code tools and tips

Mon, 07 May 2007 18:27:57 +0000

[…] Via RSS, an excellent article on code, tools, debugging and Xcode tricks. […]

By: Michael Bishop

Michael Bishop — Mon, 07 May 2007 18:18:06 +0000

For those of you using doxygen to document your code, it has a specific TODO comment which will output all it finds in a nice list for your documentation…

http://www.stack.nl/~dimitri/doxygen/commands.html#cmdtodo

By: WNAS

WNAS — Mon, 07 May 2007 18:12:39 +0000

programming tip’s (also for frontend?)…

I just read an interesting article by ‘uncle jen’ on (best) coding practices. It focuses more on C and cocoa apps, but I think that these tips will work for javascript and css just as well. Here is one:

“the main person you’re writing …

By: links for 2007-05-07

links for 2007-05-07 — Mon, 07 May 2007 17:19:25 +0000

[…] Uncle Jens’s Coding Tips — Thought Palace (tags: programming software_development tips) […]

By: Tom_E

Tom_E — Mon, 07 May 2007 16:30:19 +0000

Add me to the “don’t use _ as prefix” fraction. As Dennis already stated, that renders code using that particular class non-standard-conformant as soon as the Objective-C++ compiler includes the declaration. Of course gcc will probably never moan, but that doesn’t make the code better. IMO it’s a pity NSObjects “automatic” KVC code only allows _ as an prefix but not as an suffix.

For the -wall part, it’s rather annoying one cannot use it without hacks in Quicktime-heavy code. Especially as Objective-C errors typically are reported as warnings, and 548 deprecation warnings hide pretty much any interesting.

Last !least, the // Todo and // fixme comments pop up as a smart search in IDE’s on “other platforms”, making them much more useful (no need to fire up a project search to track them)