foo (bar)
VS
foo ( bar )
Which is it?
foo (bar)
(foo bar)
foo bar
Any language worth its salt doesn't require parens around function calls.
Which is it?
foo; bar; baz;
or
foo; bar; baz
hint: the semicolon is a binary operator
(foo)bar
C was a mistake
int foo( int bar){... function body... }
foo < bar
foo {
bar
};
That's not C, the semicolon is not an operator in C.
It should have been.
foo bar
In OCaml those parentheses could be omitted.
Isn't comma an operator in C tho?
foo.bar();
(foo (bar baz))
No
foo->bar();
op (fag )
foo(bar){ like_this();}
**** COMMODORE 64 BASIC V2 **** 64K RAM SYSTEM 38911 BASIC BYTES FREEREADY.10 FOO$20 BAR$30 PRINT FOOBAR
foo (((bar)))
{ baz ; } ( bar ) foo ;
foo[ bar; ];
been dabbling in inform 6 lately
BAR FOO
Function definition:
int foo(bar){ ...}
For statement:
for (i = 0; i < bar; ++i) { ...}
barefoot?
No, it's not an operator at all. It's just punctuation (statement termination delimiter, to be specific).
Wrong, there is one. Not every comma in C code is the comma operator though (the commas separating functions parameters aren't as they are punctuation similar to the semicolon, while the commas in a for statement are).
(self.foo)( bar,);
...
FUNCALL "{\"function\":\"foo\",\"argList\":[{\"varName\":\"bar\"}]}"
lol u take him 2 da foo bar|
int/** Brief description. * Detailed description. * @param a The first parameter * @param b The second parameter * @return The result */foo(int a, int b) { if (a != b) return a%b; if (a + b == 2) { b = a + 2; a %= b; } bar(a, b); while (a < b) { a = baz(a, b); quux(b, a); } return a*14730;}
TL;DR documentation between return type and signature, function calls and declarations have no space between ident and parens, if/while/switch (keywords) have a space before the paren, Java-style braces.
its
$::foo bar.
the absolute state of Zig Forums
I hope you mean purely functional languages with currying, where such syntax rises from function application being most tightly binging operator denoted by space.
And not brain-dead retardation that is perl & ruby syntax.
bar @ foo
foo, bar, baz.
oh no where are your endofunctors now
Please stop sniffing solvent before it's too late
[code] int foo, bar, baz;
[code] int foo, bar, baz;[code]
goddammit how do I write code?
kode with karlie
add a slash before the second code
how do I use [code] tag?
[code] syntax plox
that was my next guess.
int foo, bar, baz;
What?
#include int main(){ char input; printf("Please input characters: "); scanf("%[?]", input); if (input == 'BAR FOO') { puts("Did you say \"barefoot\"?"); puts("Because if you say \"BAR FOO\" five times fast"); puts("it sure af sounds like \"barefoot\"!"); } return 0;}
I just realize I don't know how to do character inputs yet because I haven't gotten that far in the book :-(
I was writing in FORTH. FOO would have stack effect ( x -- x') and BAR is what would be operated on
foo ((( bar = mitzva )))
interesting. I hadn't heard of that language until now. May I ask why? I mean, it seems like an obscure language, so I'd be interested to know why you decided to learn it.
I'm trudging through C right now. In a couple years, I'll be another wannabe programmer fluent in a language or two working in a coffee shop, is my guess. Kinda depressing, but I've got to give it a shot. I'm really starting to wonder whether I would want to do this for a job, though. I think I'd rather do server maintenance than code... I think. I guess I just can't imagine what the actual job would be like at this point.
should've seen that coming...
There's a unifying theme to a lot of my Haskell style, and it is this: be explicit and use names. Why pervasively use record fields? I'm being explicit about the purpose of those pieces of data by giving those fields a name. Why qualify imports? I'm being explicit about their provenance by giving their provenance a name. Why use functions or records of functions instead of typeclasses? I'm being explicit about what functionality I'm dispatching to by giving that functionality a name. A related theme is: optimize for reading code later. If it takes longer to write or uses more lines or more variable names, but it's going to be clearer to another person reading my code—or to me, coming back to that source file in a month or a year—I will absolutely take the time to write the longer code.
But also, like a mediocre high-school essay writer, I want to reiterate what I wrote at the beginning: this is one of many styles, and it has its own tradeoffs! (Verbosity being a big one here.) Your style might be (and probably is) different, and that's a good thing: in fact, I'd be interested in reading analogous posts to this one that describe the specifics of and motivation for other people's Haskell styles! I don't think there's a "wrong way" to write Haskell: there's a multiplicity of possibilities, and we as Haskell users should embrace that!
…well, unless y'all use TypeInType, in which case you're clearly depraved in ways that medical science cannot fix.
Cause programming is fun and Forth is fun. And it's way more powerful than C and the gang, just lacking in libraries (especially now it's basically dead). I write my own scripts in a dialect called Retro Forth
...
Neither. It's
foo(bar);
/thread
Because it's machine-code level of abstraction. If your other option is using assembly - FORTH might be a more productive choice. If your other option is BASIC - FORTH is only correct choice. If you have something as fancy as C compiler on your platform - you are out of FORTH use case.
For fun/educational purposes, write FORTH VM. It's simple enough that you can make decent one in one evening. Then write for it.
-[--->+-.[---->+++++-.---.--[--->+-.++[->++++.------.++++++++++++.--------.[->+++-.
well, I'm just 1wk/4ch into C programming. I went with it because it seemed like the most useful place to start and the best for the job market. I won't have a CS and I'm not sure how to get experience in the field, though, so idk if I'll ever get a job. I have degrees, just not in CS. trying to make a career switch
you could start by doing a poo in the loo pajeet
If I were a pajeet. I wouldn't have lost my career for being le ebul wyt mail blonde nazi jewkiller cishet patriarchal rape culturist
Trick question. People who waste time on this bullshit instead of fixing the real problems in their code are unemployable.
...
Your format should follow the convention set by the lead developer. This is a trivial problem for your code formatting software. This is the reason why it's meaningless to think about formatting beyond what the lead developer says.
FORTH is more productive for most software, once you think outside the C-like mindset.
Learn C++ if you want a job.
foo(bar)
bar foo .
foo( bar)
...
This should give you the functionality without any buffer overflows (although I could be wrong since I'm still a C scrub)
#include #define BUFFER_SIZE 10#define BAR_FOO_STR "BAR FOO"int main(){ char input[BUFFER_SIZE]; printf("Please input characters: "); if (fgets(input, BUFFER_SIZE, stdin) != NULL && strlen(BAR_FOO_STR) == strnlen(input, BUFFER_SIZE) && strncmp(input, BAR_FOO_STR, BUFFER_SIZE) == 0) { printf("Did you say \"barefoot\"?"); printf("Because if you say \"BAR FOO\" five times fast"); printf("it sure af sounds like \"barefoot\"!"); } return 0;}
Look up the history of the CRPG "Starflight" (published by Electronic Arts on 1989). Forth is good for making smallest compact code. Very usedul for microcontrollers and such.
Just use readline(3).
Sounds like dependency bloat for something so simple.
How do you faggots ever get any work done if you squabble over the pettiest shit like fucking intervals between brackets?
It's as if they've never heard of code formatting programs.
xd
Oh yeah, you're right, forgot about the for loop comma
Best method.
Agreed. Pack your things and leave, Javanigger.
type foo(bar, baz)type bar;type baz;{ return baz;}
foo(bar)
This thread is brainlet central
.section .dataop:.ascii "fag".section .text.globl func.type func, @functionfunc:movl $4, %eaxmovl $1, %ebxmovl $op, %ecxmovl $3, %edxint $0x80
bump