Hacker News Reader

Hacker News

Comment by raverbashing | Hacker News Reader

Parent Full thread

raverbashing

Ah the old C style of function types in a different line.

This smells of very old code (as the header testifies)

View on HN

??? This is modern BSD (and probably plan9) style. Here's a line from the header:

That's pretty recent.

And here's BSD style(9): http://www.freebsd.org/cgi/man.cgi?query=style&sektion=9

    The function type should be on a line by itself preceding the function.

I use that style all the time. I like having the function name start in column 1, it can make searching easier.

I do wish that in C1x (for x > 1), they could find a way to let us declare multiple formal arguments of the same type without repeating the type:

    float
    my_graphics_hack(float x, y, z, r, g, b, u, v) { ...

instead of

    float my_graphics_hack(float x, float y, float z, float r, float g, float b, float u, float v) { ...

which gets really tedious and obfuscates that fact that they are all the same type, especially with the typename is more complex than just "float". When the new syntax was added to ANSI C, it wasn't possible to do multiple variables, for reasons I've forgotten but which I think had to do with forward type references. It would be awfully nice to find a fix for this.

That's a poor justification, there are plenty of tools to index and search C(++) code like ctags or cscope, and your example could use a vector or a struct, I have a hard time imagining when a function with such a prototype would be useful in real life.

Compound literals are not too pretty and not too well known. Plus, if you care about c89... So, do you wrap all your values in a struct because the prototype gets too long otherwise? What a chore.

Preferring that function names start at the first column to make searching easier is a perfectly good justification.

You, on the other hand, seemingly would impose your tools (which have their shortcomings) and workflow on people with no justification at all.

Just because a tool exists, doesn't mean it's good (or better than what people are accustomed to) or that everyone must use it.

Do you think everyone should use Vim on Linux too?

No, I think everyone should use Emacs on FreeBSD, but that's not my point.

Adding syntactic sugar to a language makes the language bigger and harder to completely understand, it makes it easier to misuse a feature (and C already has a lot of trickery with types, like when you declare a parameter as an array but it behaves like a pointer). I'm a strong believer that implicit is better than explicit and that while there are many ways to do the same thing some are better than other in practice. Of course, "in practice" can change from one project to the other, what matters in consistency. I applaud the choice of Go to standardize on a single coding style for instance.

For the particular example of the parent, while I write a lot of C code for work and for fun I have yet to encounter a situation where I saw a function taking 10 floats as arguments and thinking "yup, that's completely the right way to do that". If you have an example of such a code I'd me more that willing to reconsider my position, otherwise we're just talking about the best way to tame a unicorn.

structs are a good way to hide away all that state

Agreed, but there are still times when I end up having several arguments of the same type, and I see no virtue in having to repeat the type for each formal parameter.

I don't see how having the type makes it easier to grep, grep finds the function name regardless

You can also search for something like "\w+\s(.?)\s*{"

>I don't see how having the type makes it easier to grep, grep finds the function name regardless

It's not about finding the function name in general, it's about finding where the function is actually declared -- not in the call sites.

>You can also search for something like "\w+\s(.?)\s{"*

Yeah, or use ctags. That's why they said "simpler".

"^foo" beats that.

Yeah, ctags is a good choice

> "^foo" beats that

because it's so hard to use ctags...

So how do you use ctags with grep?

It needs setup. I'd rather just grep.

BSD/Plan 9 style is extremely useful because it allows grepping for functions. More specifically, it allows the creation of acme(1) addresses of the form /some/file.c:/^foo where foo is a function. In acme you can just B3-click on that string and it will open the file at the correct function...

It is also a pretty common style in the open source world.

You can do that with ctags

> It is also a pretty common style in the open source world.

Depends, one proeminent C project doesn't use that: the linux kernel

>You can do that with ctags

And I can do it without ctags. That's the point.

>Depends, one proeminent C project doesn't use that: the linux kernel

That doesn't make his statement "depends" at all. A single project not using that style does not contradict it being "pretty common".

this is a style i still use today (almost)

    int
    main
    (int argc, char **argv)
    {
      //body..
    }

although most people think i'm weird for it..

Yep, that's pretty weird. It harks back to the early days of C. When I first saw the currently recommended form:

    int main(int argc, char **argv) {
      //body..
    }

I thought it was nice but not obviously advantageous, but over the years I've come around to thinking it makes code easier to follow. Even many bash shell scripting guides now recommend a similar form:

    for x in y; do
      # body
    done

it certainly helps when your function isn't as simple as main..!

it is so you can type

    grep -n ^functionname *.c

and get the line that starts the definition

which line?

Are you sure you aren't confusing it with K&R style with the argument names on a different line? That would indicate old code. Having the return type on a different line is incredibly common, virtually every C project with decent code uses it.

Reply on news.ycombinator.com