This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Vadim Yanitskiy axilirator at gmail.comHi Neels,
> Recently, fixeria brought up that it would be better to not
> align wrapped lines with an opening brace [...]
as you've already mentioned, I am not a big fun of such alignment.
IMHO, this coding style neither improves nor decreases the total
readability - it's just the matter of taste.
Why don't we align variable assignments then? Like this:
struct msgb *msg = (struct msgb *) data;
unsigned long msg_len = msgb_length(msg);
uint8_t *ptr = msg->data + 3;
Yes, it's aligned, but is it easier to read? Thanks to the code
highlighting, I don't see significant readability changes. But,
if we add a new variable with longer length, we would have to
realign all surrounding definitions. So, as a result we have
~same readability, but additional responsibility?
At the same time, I like the alignment we use for value_string
definitions, and for osmo_fsm definitions, because it actually
changes the readability in a better way, and doesn't require
us to realign everything in the most cases.
> My problem with that is that it also affects if- and for-
> statements: 'if' and 'for' will never change their name, so
> aligning with opening-brace is unlikely to ever cause
> unnecessary whitespace change.
Agree, for both mentioned statements we really need to distinguish
between their body and their definition, otherwise e.g. a wrapped
part of some condition may look like a part of the code to be
executed. But, there is no such problem for function definitions.
> Any (strong) opinions on / best practices for this?
Sure, we should focus on actual implementation work, but since this
question arises from time to time during this implementation work,
let's discuss it once and for all.
I would like to propose some of my ideas:
1. let's don't enforce the "opening brace alignment" during code review;
1.a. if a new file is to be introduced, the alignment style is up to the author;
1.b. the alignment style should be consistent in the whole file,
1.b. ... but if the function name is too long, let's allow a single tab;
2. let's avoid the "opening brace alignment" for the function calls, e.g.
vty_out(vty,
"Alignment makes out code great ...\n");
let's just use a single tab.
3. we should neither submit patches like "align function definitions",
nor "use a single space for alignment" to the existing code;
3.a. excepting the cases, when arguments left misaligned after the
function name change and look ugly after that;
With best regards,
Vadim Yanitskiy.