Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to make fewer errors at the stage of code writing

viva64.com

Post reply on HN
Print view View original

11–20 of 24 posts

Re: How to make fewer errors at the stage of code writing

#11

Post by barrkel »

Stormbringer wrote: post #5
barrkel wrote: post #3

Earlier quoted context omitted.

I personally detest people who do this, outside of things like tables (i.e. structured constant initializers) and comments on type definitions. If there's a high degree of regularity in the source that you're trying to expose, there's probably a better way of doing it - extracting out common variables, using a table lookup, adopting acronym conventions for regular parts along any given axis which have the same length…

Sometimes I arrange my variable declarations so that they make a picture of something in profile... ... don't hate me because I'm beautiful ... :D ---- On a more serious note, something I have noticed working on large projects with other programmers, is that if each programmer has their own distinctive style and conventions, then you can tell straight away by looking at it who wrote it, and more importantly who modif…

I strongly agree with this as well - however, when I need to overhaul a huge portion of the codebase, I may end up normalizing tabs and spacing somewhat; e.g. tabs between 'if', 'while', 'for' and '(', spaces between function / array name and '(' or '[', etc.

That is to say, I don't mind everyone being free to format code how they see fit, just don't be surprised if in rewriting or modifying it, it gets "fixed" differently.

I'm currently doing this right now at work, hence my vehemence. There's even things like this in class definitions:

    int const * const	FooBar // Yes, that's a tab
        (Foo foo, Bar bar)
which at first glance can end up looking like instance variable declarations instead of methods.

Re: How to make fewer errors at the stage of code writing

#13

Post by pilif »

Tangentially related (section 3 talks about this): why would you ever disable code using the && false idiom?

You could just remove it (and rely on you source management system to get it back) or you comment it out (where you will at least get syntax highlighting to help you spot the dead code).

It happened multiple times to me that I missed a tucked in &&false while I was porting older code to a new API. As the code was disabled anyways, I could have spared myself the time of patching it up.

Now sure, if you are just testing something during development, this might be a viable way to disable code, but something like this should not be committed. Please use proper comments or better, just remove the code.

In this light I don't understand why the article is even trying to suggest syntactical "improvements" (adding parentheses doesn't make it more readable IMHO), when the complicated expression should have just been rewritten to

    UINT uFlags;
    uFlags = DST_ICON | DSS_NORMAL;
No condition, more readable and less runtime overhead. And whoever committed this got the pleasure of committing "red lines" (git shows removed lines as red and being able to remove stuff always feels good)

Re: How to make fewer errors at the stage of code writing

#14

Post by T-R »

pilif wrote: post #13

Tangentially related (section 3 talks about this): why would you ever disable code using the && false idiom? You could just remove it (and rely on you source management system to get it back) or you comment it out (where you will at least get syntax highlighting to help you spot the dead code). It happened multiple times to me that I missed a tucked in &&false while I was porting older code to a new API. As the code…

I've definitely spent a good while in the past trying to decipher the intent of someone who used &&alwaysFalseExpression - Is it a bug? Am I overlooking some subtle side-effect somewhere? If they just wanted to turn the code off, they would have just commented it out...right?

Re: How to make fewer errors at the stage of code writing

#15

Post by loup-vaillant »

pelotom wrote: post #9

7. Don't write code in C

I know it sound unhelpful, but it isn't. If you can avoid low-level, unsafe languages like C and C++, by all means do so.

Chose a high-level language like Python, Haskell, Lisp… Anything with closures and automatic memory management, provided it let you fall back to C when you really need it.

Outside maintenance, few project need to use C or C++ all the time.

Re: How to make fewer errors at the stage of code writing

#16

Post by Luyt »

barrkel wrote: post #3
T-R wrote: post #2

> Align everything you can in code Yes. Makes code easier to read and makes it easier to refactor if you use an editor with column select/multi-line caret.

I personally detest people who do this, outside of things like tables (i.e. structured constant initializers) and comments on type definitions. If there's a high degree of regularity in the source that you're trying to expose, there's probably a better way of doing it - extracting out common variables, using a table lookup, adopting acronym conventions for regular parts along any given axis which have the same length…

I'm one of those few programmers who like to code with a proportional font. I have been declared mad as such, with the reasoning "you can't line up things with a proportional font". Well, guess what, I don't need to. I pay attention to correctly indenting my code, and that works even with proportional fonts. I find monospaced fonts hard and unnatural to read. Almost all books, magazines and newspapers use proportional fonts!

If your code needs lining up to be legible, you're doing something wrong.

Re: How to make fewer errors at the stage of code writing

#17

Post by agazso »

Osiris wrote: post #8

It seems to me that the most common errors in C/C++ are memory leak and/or corruption issues. Coming from someone who's background is in managed/garbage collected languages, doesn't using a managed language help to avoid these common mistakes? I know that it's still possible to leak memory in C#, like not releasing event handlers, but it's very difficult, if not impossible, to corrupt memory without using unsafe code…

I would say that the most common errors are because there is no built-in string type (at least in C) and lot of library function expects null terminated strings.

And these are hard to get right, because they are very prone to off-by-one errors, and novice programmers tend to write string manipulation routines from scratch, which leads to corruption.

Use libraries (e.g. bstring or std::string in C++) that do that for you, and you won't have problems.

Regarding memleaks: you can leak database handles, file handles and other resources in managed languages. In C/C++ memory is one of the resources you also take care of. In C++ there are also destructors and you can use RAII to handle most of the cases without thinking.

Re: How to make fewer errors at the stage of code writing

#19

Post by dpritchett »

mraybman wrote: post #7

For languages that support it, use lambda functions judiciously - too much of them make code really error-prone and hard to debug. (Not the most wide-spread problem, but came across this today) Also check for null!!! ;)

Your experience is the exact opposite of what I was promised by the functional programming community. Can you please elaborate on how lambdas are giving you trouble?

Re: How to make fewer errors at the stage of code writing

#20

Post by Jach »

narag wrote: post #18

Well, this one is not impressive, but I find it useful for C-like languages, Java included: if (5 == somevar) { .... If you accidentally write "=", you'll notice.

Many compilers (gcc and mxmlc come to mind) simply warn you if you try to do "if (somevar = 5)" and suggest an extra set of parenthesis to shut up the warning, if that's really what you wanted. Python throws a syntax error.
Post reply on HN