so about coding style .. do we have a style manual ?
i see this:
bool TabManager::refreshDocument()
{
bool file_opened = false;
if (!editor->filepath.isEmpty()) {
…
file_opened = true;
}
}
return file_opened;
}
so this is using a status flag to report pass/fail to the calling routine.
This does have only one way out, the return at the end.
but the style i like to use .. return as soon as you know you want out
but there are two ways out …
bool TabManager::refreshDocument()
{
if ( editor->filepath.isEmpty())
return false;
// do rest of code
return true;
}
do we care? so we allow individual freedom of expression in our source code?
and .. is there a Manual of Coding Style for OpenSCAD?
From my 37+ professional years of coding avionics software, I'd strongly
recommend a single exit. Never make the maintainer search for and try to
guess which exit was taken.
On Tue, Sep 23, 2025 at 10:48 AM vulcan_--- via Discuss <
discuss@lists.openscad.org> wrote:
i see this:
bool TabManager::refreshDocument()
{
bool file_opened = false;
if (!editor->filepath.isEmpty()) {
…
file_opened = true;
}
}
return file_opened;
}
so this is using a status flag to report pass/fail to the calling routine.
This does have only one way out, the return at the end.
but the style i like to use .. return as soon as you know you want out
but there are two ways out …
bool TabManager::refreshDocument()
{
if ( editor->filepath.isEmpty())
return false;
// do rest of code
return true;
}
do we care? so we allow individual freedom of expression in our source
code?
and .. is there a Manual of Coding Style for OpenSCAD?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
and .. is there a Manual of Coding Style for OpenSCAD?
No.
On 23.09.25 18:19, Leonard Martin Struttmann via Discuss wrote:
From my 37+ professional years of coding avionics software, I'd
strongly recommend a single exit. Never make the maintainer search for
and try to guess which exit was taken.
(Disclaimer: I don't know about avionics and the rules involved
there which are hugely important, obviously. I do have worked on
many big projects digging through >20 years old code, so I know
a bit about maintenance and technical debt)
While I generally agree the single exit has benefits, but
introducing booleans that are updated along a possibly long
path is bad too from a maintenance perspective.
So for OpenSCAD, my suggestion would be somewhere in the
middle with an additional requirement I'll come back to.
As said above, there's no official OpenSCAD manual for this,
so here's my personal recommendation.
- If you have validation blocks in the beginning, doing a
return there is fine. If the conditions are more complex, use
immutable variables to document them... pseudo-code-ish...
if (!doc) {
return 0;
}
const bool is_readonly = check_readonly(doc);
const bool is_empty = doc.get_document_size().trim() == 0;
if (is_empty || is_readonly) {
return 0;
}
-
If the validation code gets more complex, introduce a
function, then goto rule 1) -
For the actual execution code after the validation blocks
try to stick to the single exit at the end.
Coming back to the other useful requirement, that would be
"keep functions short", ideally less than a page. I'm
fine with accepting modern hardware, meaning I prefer to
have lines a bit longer and not wrapped in an unreadable
way just to keep them under 80 characters.
And again exceptions exist. Mostly GUI setup code. But
don't follow the horrible mess that is MainWindow.cc :-).
ciao,
Torsten.
From my 37+ professional years of coding avionics software, I'd strongly recommend a single exit. Never make the maintainer search for and try to guess which exit was taken.
Yes, though the flip side (for non-trivial functions) is that that often comes with additional complexity in the path taken to get to the single exit.
In a simple function anything works, but to use the one quoted as an example… if you’re looking at the return you have to search for where the variable got set, and if you’re looking at the test where it sets the variable you have to look to see if anything changes the value before the return.
Torsten Paul wrote:
and .. is there a Manual of Coding Style for OpenSCAD?
No.
On 23.09.25 18:19, Leonard Martin Struttmann via Discuss wrote:
From my 37+ professional years of coding avionics software, I'd
i have a similar time in service and a lot of it doing maintenance of code anywhere up to
50 years old. you all know what that means eh?
I do respect the concept of one exit .. but when trying to understand convoluted old
code being able to see the parameter checking clearly trumps the theory of
Maintainable Code
so here's my personal recommendation.
- If you have validation blocks in the beginning, doing a
return there is fine. If the conditions are more complex, use
immutable variables to document them... pseudo-code-ish...
yeah, my preference also
- If the validation code gets more complex, introduce a
function, then goto rule 1)
amen .. choir here
- For the actual execution code after the validation blocks
try to stick to the single exit at the end.
okay .. that tells me what i need to do
thanks all for the input
On Tue, 2025-09-23 at 15:48 +0000, vulcan_--- via Discuss wrote:
i see this:
bool TabManager::refreshDocument()
{
bool file_opened = false;
if (!editor->filepath.isEmpty()) {
…
file_opened = true;
}
}
return file_opened;
}
so this is using a status flag to report pass/fail to the calling
routine.
This does have only one way out, the return at the end.
but the style i like to use .. return as soon as you know you want
out
but there are two ways out …
bool TabManager::refreshDocument()
{
if ( editor->filepath.isEmpty())
return false;
// do rest of code
return true;
}
do we care? so we allow individual freedom of expression in our
source code?
Allow? Really? Suggest I can accept.
and .. is there a Manual of Coding Style for OpenSCAD?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
larry wrote:
On Tue, 2025-09-23 at 15:48 +0000, vulcan_--- via Discuss wrote:
do we care? so we allow individual freedom of expression in our source code?
Allow? Really? Suggest I can accept.
the wording was only for comic effect .. and in fact .. remembering the beautify workflow in GitHub ..
effectively we do have a coding style as far as indentation and braces placement goes .. whatever
is setup in clang-format is enforcing a standard.