So?
What are your preferences?
also updated
~(function fuckOff () {})();
>>53258136
don't be so mad, anon!
function foo() {
}
var foobar
Opening bracket on same line.
No space padding for variables inside parenthesis.
Variable naming depends on language.
>Variable naming depends on language.
That's odd
>>53258105
pairs of parentheses, braces and brackets forming a block are aligned to the same column, unless the block is very small (like in most function/method calls). if the block is small enough to keep them on one line, no spaces are left before or after them.
function names, method names, variable names are camelCase.
class names are CapitalizedCamelCase.
constants, defines etc. are ALL_CAPS_WITH_UNDERSCORES
>>53258219
This, and with func(args) touching.
foo( fooBar ) {
}
>>53258598
>>53258105
Depends on the language and coding standards of an organization
>>53258598
Get out.
>>53258219
This, I've had to go through code and fix this problem too many times, I've even left a project dead in its tracks finding that the devs were so incompetent.
int foo(int arg1, char arg2)
{
int fooBar = 0;
while(fooBar < 10)
{
++fooBar;
}
}
>he doesn't use GNU/Style
>>53259442
>while(
dropped
>>53259584
>while (
absolutely disgusting
function foo()
{
}
var foo_bar =
function(args)
>>53258105
#define FUCKING_DEFINE 1
void function(int iArgument1, char* cArgument2) {
//type_tab_name_tab_value;
int iVariable = 0;
string sText = "4chan/g/";
char* cArray = {
'a', 'b', 'c',
'd', 'e', 'f',
'\0'
};
for(int i = 0; i < 10; ++i) {
std::cout << i << '\n';
}
}
>>53259420
> brackets aren't in the same column
> walk away from a project
Those guys don't know how lucky they were!
>>53259676
Please put this in code bookends or moot will fuck your sister.
>>53259676
>fix
#define FUCKING_DEFINE 1
void function(int iArgument1, char* cArgument2) {
//type_tab_name_tab_value;
int iVariable = 0;
string sText = "4chan/g/";
char* cArray = {
'a', 'b', 'c',
'd', 'e', 'f',
'\0'
};
for(int i = 0; i < 10; ++i) {
std::cout << i << '\n';
}
}
>>53259681
I'm talking about overall incompetence with code not just syntax.
I like girls from time to time mostly sexually tho. But for a romatic/loving actual stable relationship I prefer guys, sex still good but more painful.
>>53258105
>>53258105
Camel case for days nigga
>>53263141
mah nigga
>>53258105
Whatever the current code style dictates, I have a vim script which can enforce a certain code style and I can enable different code styles for different projects. I can type my code however I want in what ever way is comfortable for me and the vim script will automatically change it to fit the given code style. Keeps me and the people I work with sane.
>>53258105var foo_bar = foo(args) {
};
var FoO_BaR = foo(
args
)
{
};
>>53258696
Your preference depends on what the dumbest developer before you can handle?
>>53263726
this
>>53263765
I always laugh at muh readability aegument.
Not being able to read code with different spacing is like not being able to read articles with different fonts.
>>53258105
Top on all 3
dam, I have the biggest debate with myself about
foo(){
}
vs
foo()
{
}
but I think I'm going to stick with the top one because it's one less line of code
public int FooBar;
private int _fooBar;
void Method(int arg)
{
var fooBar = OtherMethod(arg);
}
>>53263141
finally someone intelligent
>>53263141
fucking yes
I have not yet heard a single valid reason to keep { on a separate line.
>>53265766
It's just about readability, the indentation is clearer if you place it on a new line since it lines up with the closing brace. However, if you value number of code lines or vertical space obviously it's a luxury.
>>53263141
This.
Sometimes i usefunction foo()
{
}
but only in C.
This one :^)
>>53259676
>me#include <cstdio>
#define FUCKING 1
static constexpr uint32_t SHITTING 2;
void function (
int32_t argument1,
char* argument2
) {
// fuck your tabs
int32_t variable = 0;
const char* text = "4chan/g/";
char array[] = {
'a', 'b', 'c', 'd', 'e', 'f', '\0'
};
for (int32_t ii = 0; ii < 10; ++ii)
{
printf("%d\n", ii);
}
}
>>53266089
Java is gay as fuck. i just spent 3 hours trying to creating a fucking JAR file, but the shell was keeping to say it can't located the main class even if i write it correctly in the maifest. and then it just say it was ok.
and you know what else is gay? your shitty b8 indentation
C master race
Also this is how i write
int writeFileClass(char* nameMain, FILE* file) {
int ctrl;
ctrl = fprintf(file, "Main-Class: %s\n", nameMain);
if (ctrl > 0) {
return NO_ERROR;
}
else {
return WRITE_ERROR;
}
}
>>53266158for (int32_t ii = 0; ii < 10; ++ii)
What did he mean by this.
>>53265766
It's a lot easier to identify scope of statements when you have the beginning and ending brackets of the same column in my opinion.
>>53265766
And I have not yet heard a valid reason for keeping it on the same line.
What was always batshit to me was people who'd explain it as saving vertical space, then put every one of their function arguments, including the first, on a separate line. And not just in declarations, calls too. They'd have this hissy fit about scrolling a little to the right sometimes, then make me scroll down a full page to see local variables or the inside of an elseif block.
>>53266544
i think it vinculates the int type to a size which is know?
it's vinculate a word? i'm too lazy to check
If your not a retard and force yourself to one convebtion., and use the convention that was made for the language you are using.
This would not be a argument at all, it only is because people can't handle change.
int power_of_number(int base, int exp)
{
return base**exp;
}
int powerOne = power_of_number(1, 8)
int powerTwo = power_of_number(2, 8)
...
int powerEleven = power_of_number(11, 8)
>>53266661
It's not an argument until some busybody or committee of them use these arbitrary rules to make half the language features off limits while creating WTF after WTF themselves.
>>53264820
my nigger
>>53266568
The statement itself is the beginning of the block, and is semantically all that matters. If you look at ALGOL for example, something C is heavily based on, it does code like this:IF x THEN
foo
ELSE
bar
FI
In this example, why on earth would you put THEN on a new line? Because that's essentially what you are doing by placing a brace on a new line. It adds no new semantic information and wastes space.
>>53266622
Because semantically it makes more sense to put it on the same line as the statement that opens the block.
This one(foo-bar args)
>>53258105
IT FUCKING DEPENDS ON THE LANGUAGE YOU COCKSUCKER
>>53266837
But the brackets are what open and close the block, not the conditional statement.
>>53267204
The opening brace is semantically part of the statement. The brace itself is simply minor syntax.
>>53267308
Then omit both braces.
>>53266544
>ii
I use two characters for counter variables and stuff because it's easier to see for me.
>int32_t
An int32_t is guaranteed by the standard to behave as a 32 bit two's complement number. See `stdint.h` for details. I prefer fixed width types for ensuring consistent program semantics. If I ever need to port the code to a platform where, say, and int32_t can't exist then I will get a compiler error and have an indication of needing to fix the problem. I work primarily in embedded so this kind of thing is a vague concern.
