How would you tell the compiler otherwise which statements belong to the function?

Your suggestion would work if all functions always had only 1 statement.

And if you're going to say "Yeah but the statement is behind the declaration, and thus I'm indicating that that is all that belongs to the function" you're going into the madness that is python I believe where whitespaces actually have meaning.

>>5640
Not OP, but I've wondered this.
For if statements, you can have:

if(x) y();

or

if(x){ y(); }

So, why not for functions? If you want more than one line in a function, you must add braces.

Python.

Also, it's done for readability. Makes it easy to see exactly what part of the code belongs to what header.

>>5641
OP here. Indeed. It appears to be quite arbitrary. There are clearly benefits, otherwise it wouldn't be kept for ``if'' statements. I might have an idea, there is the dangling else problem:

if (foo) if (bar) mu(); else zot();

or is it:

if (foo) if (bar) mu(); else zot();

Likewise, this could apply to try/catch:

try try foo(); catch bar();

It becomes confusing to a reader and parens must be stuck in to make it clear. BUT we recognize that there are benefits to not using braces. And we're not nesting them all the time. Anyhow, functions only have one branch anyway so this problem doesn't even apply to them.

What an annoying inconsistency.

Rage building...

>>5642
I call bullshit.

>>5644
Disregard the try/catch one, a try is meaningless without a catch or finally clause.

>>5642

OH HALP ME I CAN'T BE BOTHERED TO READ OTHER TWO LINES OF MAH CODE

>>5650
> I CAN'T BE BOTHERED TO WRITE OTHER TWO LINES OF MAH CODE
fix'd

You could just do this:
string hello() {return "Hello, World!";}

>>5650
>>5644
I stand by it. What's the pain in writing two additional characters? It helps ensure a page of code is unitized.

Write your own parser.

Enjoy the enlightenment that then occurs.

Blocks have their own variable scope, or stack if you will. Functions are constructs that take in parameters and hence must have their own scope otherwise pass-by-value semantics won't work.

That's the boring history-lesson version anyway.

My own version is: WTF ARE YOU DOING WRITING 1-LINE FUNCTIONS ANYWAY

>My own version is: WTF ARE YOU DOING WRITING 1-LINE FUNCTIONS ANYWAY

Indeed.. you can do it like this

#define hello() "Hello, World!"

strcpy(some_string, hello());
-or-
printf("%s\n", hello());

:)

>>5684
>>5641 here
Makes sense, but don't if statement blocks have their own scope too?

>>5657
> What's the pain in writing two additional characters? It helps ensure a page of code is unitized.

I don't think you know what "unitized" means.

There is pain because it takes up space, I have to write more and manage more code. Writing code isn't just about typing it out in one go you realise, code has to be edited. More syntactic characters is more time.

It is also inconvenient to read. If I am reading

if (foo) { someStuff(and(extra),stuff); }

vs

if (foo) someStuff(and(extra),stuff);

I'd prefer the latter because I have to inspect the former to count how many statements there are. With the latter I do not. I know syntactically that no braces means one statement.

> WTF ARE YOU DOING WRITING 1-LINE FUNCTIONS ANYWAY
Some functions are just one line of code. Get it?

>>5698
Yes, they do. >>5684 doesn't have a clue what he's talking about or is trying to troll us.

Anyone actually have a good reason?

>>5699
Yes. Code has to be edited, re-visited, and seen by other people. That's why you don't write code like you did in your example.

A more important point: what are you guys writing that needs so many single-line functions that it saves any meaningful amount of time/effor? Single-liners rarely happen outside of get() and set() methods.

>>5700
> Yes. Code has to be edited, re-visited, and seen by other people. That's why you don't write code like you did in your example.

I just explained in my post why I thought it was more readable. So you have essentially said "I don't think that's true", well, whoop-de-do. How about some refutation and counterargument, if you are capable?

> A more important point: what are you guys writing that needs so many single-line functions that it saves any meaningful amount of time/effor?

Not really an important point, because...

> Single-liners rarely happen outside of [common occurrence]

Yup. Other examples include method overloading, mathematical functions, string manipulation, [any piece of code that shouldn't be repeated]. I can't believe I'm actually having to argue the case for a function of any short length. Short functions are good functions.

What's your problem with short functions? Is this some kind of desperate straw man to argue against to prove that the convenient and easy to read braceless function declaration is somehow a bad idea?

>>5701
Not short functions, single-line functions. As in print-functions and get/set methods.

Also, non-braced functions are not any more convenient or easy to read than braced functions. I've yet to see anyone offer evidence for that.

>>5701
Creating a single-line function to avoid repetition sort of misses the point, because instead of the single line in your function you are now repeating calls to your function.

Supposedly this has something to do with function definitions being "special" from the parsers poit of view, and not being part of the statement/expression division that takes part inside the functions.

>>5699
God damn, why does every /pr/ thread turn into high-school at some point? Back to your angsty blog please

>>5703
> Creating a single-line function to avoid repetition sort of misses the point,

Speaking of missing the point...

You are either completely retarded or trolling me.

DebugMsg("Excellent work, Nigel."); vs. Console.WriteLn(String.Format("Debug message: Excellent work, Nigel."))

A one lined function.

> Supposedly this has something to do with function definitions being "special" from the parsers poit of view, and not being part of the statement/expression division that takes part inside the functions.

Yeah, we can see that the parser doesn't do it. Thanks. Go back to bed.

> God damn, why does every /pr/ thread turn into high-school at some point? Back to your angsty blog please

Pic related.

> Also, non-braced functions are not any more convenient or easy to read than braced functions. I've yet to see anyone offer evidence for that.

You're sitting around waiting for bullshit evidence that's about as likely as evidence that braced functions are any more convenient or easy to read than braced functions. I've yet to see anyone offer evidence for that.

>>5708
>>You're sitting around waiting for bullshit evidence that's about as likely as evidence that braced functions are any more convenient or easy to read than braced functions. I've yet to see anyone offer evidence for that.

Okay. Well let's pin it down to languages then, so we can see what looks better and what doesn't. Perl is a no-go, purely based on it being a procedural language. It also wouldn't work in Java and C# due to nested classes, anonymous classes, etc.

So um. What language are we talking about again?

>>5708
In C, a #define would generally be more suitable than a function for a onliner like that.

>>5711
Yeah, but single-line functions are totally negligible. It's adding extra effort to the parser for no gain.

Ok I'll just go ahead and assume OP is hinting at C as an extension of what >>5710 deduced.

As a good practice, each line should have as few sequence points as possible, preferrably 1 only.
http://c-faq.com/expr/seqpoints.html
This is to improve code readability, debugging, and avoid side effects. Clearly such a line will comprise little more than a handful of instructions. When you try to write a single line function, the overhead of context switching, copying parameters and so forth mean that you're practically incurring a 50% speed penalty, than just copying and pasting whatever one-liner that function was supposed to do. So again, why are you writing one line functions.

Now this is C we're talking about so get/set functions don't come into this. C# has the concept of properties which greatly simplifies writing getter/setters but still needs braces, because that makes the syntax consistent. Plus modern managed languages seem more verbose than C/C++ so two extra chars in their environment are even less significant.

>>5698
>Makes sense, but don't if statement blocks have their own scope too?
not if you don't include a block, which means a new scope is created. Single line if statements have no additional scope - why would they, when you can't declare variables and use them within one line.
Well ok, you can do

if(true) int a = 3;

but IIRC that'll trigger warnings if you compile with -anal -retentive

>>5708
sprintf("%d is a %s and needs 2 lurn 2 not use the console", 5708, "nigger");
</troll>

#define hello() "Hello, World!"

>>5723
> Ok I'll just go ahead and assume OP is hinting at C
Not sure how you got C from my various blatant C# snippets.

> When you try to write a single line function, the overhead of context switching, copying parameters and so forth mean that you're practically incurring a 50% speed penalty, than just copying and pasting whatever one-liner that function was supposed to do.

Typical C programmer; obsessed with CPU cycles. To you, I suppose, spending a load of time optimising every line of code is a better use of time, than, say, spending a short time writing big systems that actually do something.

I don't think "having a function incurs a speed hit" is a very good argument against a function that happens to contain one sequence point.

int max(int a, int b) { return a > b? a : b; }

void DebugMsg(string msg) { Console.WriteLn("Debug message: " + msg); }

Some thing just shouldn't be repeated. What if I want to change "Debug message: "?

Do you propose that for functions like this we ought to use macros because of the speed hit?

I'm not convinced that the speed hit of calling a function is particularly bothersome for most of the code of most of the software out there. Oh no, my debug messages aren't fast enough?

... but I do have a morbid interested in anyone advocating macros.

> So again, why are you writing one line functions[?]

I like abstract, maintainable, readable code, which demands means of abstraction like functions. I have no anal speed concerns, therefore the length of those functions is of no concern either. (If I had speed concerns, I'd be optimising hot spots anyway.)

>>5733
But again, how often do you write functions like that? Maybe one in two hundred lines?

>>There is pain because it takes up space, I have to write more and manage more code.

That's a stupid reason btw.. Go visit the obfuscation contest website (http://www.ioccc.org/main.html) and see how they put entire games into just a few lines of code.

It's not readable, but hey it's short right?

Manageable code isn't short, it's _understandable_. It's not short, it's _concise_. There is a big difference there.

So I think you are barking up the wrong tree here.

Also, for those who say that a one line function is too slow, that's what the __inline__ directive was made for.

Everyone in this thread is an idiot.

They probably require braces because they had a parser issue with old-style C functions.

[pre] int printline (x) char * x; { printf ("%s\n", x); } [/pre]

All this "force you to write beautiful code" shit is just unbearably stupid.

>>5760
> That's a stupid reason btw.. Go visit the
No.

> [A load of bullshit]. So I think you are barking up the wrong tree here.

I think you're barking up the wrong tree if you wish to convince me by strawman fallacy that braceless functions are neither manageable, understandable or concise because some code you saw that was short was unreadable. Short code is not necessarily unreadable. If it's equally as readable when shorter, why waste brain cycles, screen space and editing time on more syntax?

>>5734
> But again, how often do you write functions like that?
And again: often enough.

>>5763
More convincing than any of the other points in this thread.

>>5775
Neither C# nor Java could possibly have braceless functions.

sure is high-school in there

>>5782
Keep saying "high school" and eventually someone will think you're being insightful.

>>5708
what are you doing with a furry pic?

sure is high-school in here

This thread:

What OP said:
"Why do all functions need braces?"

What OP meant:
"I have this great idea and I want you all to admit that it's great and I'm great"

[Several reasons, some valid some speculative]

OP: Waaah you're all stupid

Another day in a programming chan board, I guess.

OP, you are strange.
On one hand, you need one-line functions in order to wirte readable code. On the other hand, you dislike the fact that C standart forces you to write readable code.