next »

[Ordnas]

I remember Bjarne Stroustrup mentioning in his book his ideal lines per function of around 10, against the 40 lines per function that much everyone else consider the optimal one. I am confortable with that, it is more probable that it will come out a more modular code.

Opinions differ on whether one should listen to Bjarne Stroustrup when it comes to programming but regardless of whoever says it I highly disagree with that and prefer this as external advice if any should be given:

http://number-none.com/blow/john_carmack_on_inlined_code.html

In my code you will find super short functions but you'll also find one or two that are a few hundred lines of code - my recent prototyping playground has like three 1k+ line functions. Now I'd say that's probably too much but I don't think you can always chunk up code into 10, 20, 30, 40 or even 100 line segments without hurting readability.

As with most things I agree entirely with John C. here. I generally only break code up into functions if there's repeated code. If a function is doing the one thing it's designed to do, and there's no repetition in the code then I really don't care how long it gets. There's nothing I hate more than having to jump all over a file just to follow a straight line of logic.

Very interesting the link to the page. I agree to do not create a function if that do not solve repeated code. Jumping from function to function can break the readability, but I suspect that if there are too many jumps from different source files, could that be a sign of a bad design choice? I do not expect more that 10 function jumps to accomplish the result you need.

[J-Snake]

It actually doesn't matter how long the code is and whether it is repeated or not. It all comes down to this: When a code sequence forms a significant logical unit with respect to your point of view, put it in a sound function.

[DireLogomachist]

It actually doesn't matter how long the code is and whether it is repeated or not. It all comes down to this: When a code sequence forms a significant logical unit with respect to your point of view, put it in a sound function.

Hear hear!

[oahda]

I mean, number of lines is really arbitrary depending on one's style too. I try to keep things readable and therefore avoid having to scroll horizontally as much as possible, and if a function (like some OpenGL functions for example) take a lot of parameters, I'll split them up on one line each and suddenly we go from one line to 10+.

Code:

glTexImage2D(GL_TEXTURE_2D, 0, mode, static_cast<GLsizei>(width()), static_cast<GLsizei>(height()), 0, mode, GL_UNSIGNED_BYTE, pixels());

→

Code:

glTexImage2D
(
	GL_TEXTURE_2D,
	0,
	mode,
	static_cast<GLsizei>(width()),
	static_cast<GLsizei>(height()),
	0,
	mode,
	GL_UNSIGNED_BYTE,
	pixels()
);

But maybe that counts as one line according to such measurements because there is only one semicolon?

[JWki]

I mean, number of lines is really arbitrary depending on one's style too. I try to keep things readable and therefore avoid having to scroll horizontally as much as possible, and if a function (like some OpenGL functions for example) take a lot of parameters, I'll split them up on one line each and suddenly we go from one line to 10+.

Code:

glTexImage2D(GL_TEXTURE_2D, 0, mode, static_cast<GLsizei>(width()), static_cast<GLsizei>(height()), 0, mode, GL_UNSIGNED_BYTE, pixels());

→

Code:

glTexImage2D
(
	GL_TEXTURE_2D,
	0,
	mode,
	static_cast<GLsizei>(width()),
	static_cast<GLsizei>(height()),
	0,
	mode,
	GL_UNSIGNED_BYTE,
	pixels()
);

But maybe that counts as one line according to such measurements because there is only one semicolon?

You should get a wider screen. :p  also yeah that only counts as one in my book.

[oahda]

I actually have a high resolution even in full laptop mode, but as a result I cram a lot of stuff onto one screen instead, like multiple code editors side by side, and I want to be able to read them all at the same time without scrolling or resizing too much.

[Ordnas]

I mean, number of lines is really arbitrary depending on one's style too. I try to keep things readable and therefore avoid having to scroll horizontally as much as possible, and if a function (like some OpenGL functions for example) take a lot of parameters, I'll split them up on one line each and suddenly we go from one line to 10+.

Code:

glTexImage2D(GL_TEXTURE_2D, 0, mode, static_cast<GLsizei>(width()), static_cast<GLsizei>(height()), 0, mode, GL_UNSIGNED_BYTE, pixels());

→

Code:

glTexImage2D
(
	GL_TEXTURE_2D,
	0,
	mode,
	static_cast<GLsizei>(width()),
	static_cast<GLsizei>(height()),
	0,
	mode,
	GL_UNSIGNED_BYTE,
	pixels()
);

But maybe that counts as one line according to such measurements because there is only one semicolon?

You should get a wider screen. :p  also yeah that only counts as one in my book.

Usually if I need to pass a lot of arguments I pack everything in a struct.

[JWki]

I mean, number of lines is really arbitrary depending on one's style too. I try to keep things readable and therefore avoid having to scroll horizontally as much as possible, and if a function (like some OpenGL functions for example) take a lot of parameters, I'll split them up on one line each and suddenly we go from one line to 10+.

Code:

glTexImage2D(GL_TEXTURE_2D, 0, mode, static_cast<GLsizei>(width()), static_cast<GLsizei>(height()), 0, mode, GL_UNSIGNED_BYTE, pixels());

→

Code:

glTexImage2D
(
	GL_TEXTURE_2D,
	0,
	mode,
	static_cast<GLsizei>(width()),
	static_cast<GLsizei>(height()),
	0,
	mode,
	GL_UNSIGNED_BYTE,
	pixels()
);

But maybe that counts as one line according to such measurements because there is only one semicolon?

You should get a wider screen. :p  also yeah that only counts as one in my book.

Usually if I need to pass a lot of arguments I pack everything in a struct.

Yeah same, but I guess this was also including library functions you have to call.
I have lots of functions that would take quite a lot of arguments so I too just pass a struct - similiar to what Vulkan or most Windows/D3D APIs do, but I usually initialize the struct with sensible defaults. One of the advantages of C++.

[qMopey]

Never really liked C++ style casts. To this day still just use C casts (except at work, they have a policy to use C++ casts). Personally I find the C++ casts verbose and sort of pointless.

[oahda]

Sure, I try to write my own functions so that they don't need to be split up like that but with external API's I have to play by their rules.

As for casts, I think it's nice to declare the purpose of each cast a little more explicitly.

[qMopey]

As for casts, I think it's nice to declare the purpose of each cast a little more explicitly.

Oh definitely. It's too bad static_cast<thing>(other_thing) and friends are so verbose 

[powly]

The only casts I’ve done that verbosely have been reinterpret_casts for CRTP (which btw usually results in beautifully elegant user code and absolutely terrible library code), which unfortunately is even longer than static_cast 

Is casting from unsigned to GLuint even an actual cast though? I’m relatively confident they should be the same type in a sane setting (no embedded systems involved)

[Ordnas]

Is casting from unsigned to GLuint even an actual cast though? I’m relatively confident they should be the same type in a sane setting (no embedded systems involved)

In Windows, it is just a typedef, gl.h line 149: https://stackoverflow.com/questions/8932912/whats-the-advantage-of-using-gluint-instead-of-unsigned-int
then on different systems unsigned int has different sizes.

[oahda]

It was, because for some reason, my width and height weren't unsigned, but of course they should be. Fixed now.

[Photon]

Sorry guys! I kinda disappeared for a bit because I was moving homes. Thanks for some interesting conversation!

1. Rule of Modularity: Write simple parts connected by clean interfaces.
2. Rule of Clarity: Clarity is better than cleverness.
3. Rule of Composition: Design programs to be connected to other programs.
4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
8. Rule of Robustness: Robustness is the child of transparency and simplicity.
9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
10. Rule of Least Surprise: In interface design, always do the least surprising thing.
11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
12. Rule of Repair: When you must fail, fail noisily and as soon as possible.
13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
16. Rule of Diversity: Distrust all claims for “one true way”.
17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

Oof, ignoring the "Rule of Economy" is probably something that shoots me in the foot way more than it should.

As another aside, I'm one of those people who has never really latched onto the "only x lines per function" idea. I would side with J-Snake on this one: you write a function as a cohesive unit of logic.

[Ordnas]

Sorry guys! I kinda disappeared for a bit because I was moving homes. Thanks for some interesting conversation!

1. Rule of Modularity: Write simple parts connected by clean interfaces.
2. Rule of Clarity: Clarity is better than cleverness.
3. Rule of Composition: Design programs to be connected to other programs.
4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
8. Rule of Robustness: Robustness is the child of transparency and simplicity.
9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
10. Rule of Least Surprise: In interface design, always do the least surprising thing.
11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
12. Rule of Repair: When you must fail, fail noisily and as soon as possible.
13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
16. Rule of Diversity: Distrust all claims for “one true way”.
17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

Oof, ignoring the "Rule of Economy" is probably something that shoots me in the foot way more than it should.

As another aside, I'm one of those people who has never really latched onto the "only x lines per function" idea. I would side with J-Snake on this one: you write a function as a cohesive unit of logic.

The list of rules are very inspiring to write better code for sure. I am wondering if that would be always possible, mainly in game programming, where the time constrain invites you to write fast-not reusable code.

[Photon]

Sorry guys! I kinda disappeared for a bit because I was moving homes. Thanks for some interesting conversation!

1. Rule of Modularity: Write simple parts connected by clean interfaces.
2. Rule of Clarity: Clarity is better than cleverness.
3. Rule of Composition: Design programs to be connected to other programs.
4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
8. Rule of Robustness: Robustness is the child of transparency and simplicity.
9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
10. Rule of Least Surprise: In interface design, always do the least surprising thing.
11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
12. Rule of Repair: When you must fail, fail noisily and as soon as possible.
13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
16. Rule of Diversity: Distrust all claims for “one true way”.
17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

Oof, ignoring the "Rule of Economy" is probably something that shoots me in the foot way more than it should.

As another aside, I'm one of those people who has never really latched onto the "only x lines per function" idea. I would side with J-Snake on this one: you write a function as a cohesive unit of logic.

The list of rules are very inspiring to write better code for sure. I am wondering if that would be always possible, mainly in game programming, where the time constrain invites you to write fast-not reusable code.

They'd probably be better as something you reflect on every once in awhile. Ironically, I'd guess the "Rule of Economy" works against several of these rules from time to time.

[bateleur]

Ironically, I'd guess the "Rule of Economy" works against several of these rules from time to time.

Which is good, because that reflects the nature of programming as an activity. No style guide can tell you how to resolve tradeoffs in specific cases.

[Photon]

Ironically, I'd guess the "Rule of Economy" works against several of these rules from time to time.

Which is good, because that reflects the nature of programming as an activity. No style guide can tell you how to resolve tradeoffs in specific cases.

As someone who has been trying to incorporate ECS into nearly everything for the last year, I can attest to this.

[popawheelie]

My go to rule has always been that you should be able to understand what the code is doing in less than 15 seconds. If it takes longer: rewrite, improve formatting or comment.

Sometimes Ill take a slightly less efficient route if it's easier to understand down the line.