Hi all,
for a bit of bikeshed fun on the side, I'd like to ask your opinions on a good name.
The background: we're in the process of separating libmsc from libbsc. Both use the structs gsm_network and gsm_subscriber_connection, and both of these structs contain elements that are used only by libbsc or only by libmsc, besides the elements that are used by both. So at some point I will "split" both of these in two, to have a BSC and an MSC version thereof.
How should we name them?
struct gsm_network (note, if there is a common part, that could still be named 'gsm_network')
--> bsc_network / msc_network looks familiar but the meaning of the name is lost
--> gsm_bsc / gsm_msc
--> osmo_bsc / osmo_msc To me these would be the best and the names are still available, but there are header files named like this and the osmo-bsc binary also has a very similar name. I think I would go for these anyway. +1
--> osmo_gsm_bsc / osmo_gsm_msc As alternative, but the gsm is a bit out of place (particularly in the light of a UMTS MSC).
struct gsm_subscriber_connection
--> bsc_subscriber_connection / msc_subscriber_connection but we could use the opportunity to shorten the name
--> bsc_subscr_conn / msc_subscr_conn I like these best; but add osmo? +1
--> osmo_bsc_subscr_conn / osmo_msc_subscr_conn almost the old length.
Happy shedding, "+1" comments and/or opinions welcome
~Neels
Hi Neels,
On Fri, Nov 11, 2016 at 12:50:01PM +0100, Neels Hofmeyr wrote:
struct gsm_network (note, if there is a common part, that could still be named 'gsm_network')
--> bsc_network / msc_network looks familiar but the meaning of the name is lost
--> gsm_bsc / gsm_msc
--> osmo_bsc / osmo_msc To me these would be the best and the names are still available, but there are header files named like this and the osmo-bsc binary also has a very similar name. I think I would go for these anyway. +1
--> osmo_gsm_bsc / osmo_gsm_msc As alternative, but the gsm is a bit out of place (particularly in the light of a UMTS MSC).
In general we shouldn't call structures how we are (or might be) calling functional elements. So if it's a msc or bsc instance or context, postfix it by _inst, _instance, _ctx or _context.
Also, the osmo_ naming prefix makex mostly sense in the conext of library code to avoid namespace pollution. I think I actually like it if application code structures and symbols do not have osmo_ prefixes.
struct gsm_subscriber_connection
--> bsc_subscriber_connection / msc_subscriber_connection but we could use the opportunity to shorten the name
--> bsc_subscr_conn / msc_subscr_conn I like these best; but add osmo? +1
fine with me.
On Fri, Nov 11, 2016 at 02:58:07PM +0100, Harald Welte wrote:
In general we shouldn't call structures how we are (or might be) calling functional elements. So if it's a msc or bsc instance or context, postfix it by _inst, _instance, _ctx or _context.
Also, the osmo_ naming prefix makex mostly sense in the conext of library code to avoid namespace pollution. I think I actually like it if application code structures and symbols do not have osmo_ prefixes.
--> bsc_subscr_conn / msc_subscr_conn I like these best; but add osmo? +1
fine with me.
So for now my finalists are: gsm_network --> bsc_ctx / msc_ctx and gsm_subscriber_connection --> bsc_subscr_conn / msc_subscr_conn
Speak now or forever hold your peace...
~N
On 11 Nov 2016, at 06:50, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
Hi all,
for a bit of bikeshed fun on the side, I'd like to ask your opinions on a good name.
The background: we're in the process of separating libmsc from libbsc. Both use the structs gsm_network and gsm_subscriber_connection, and both of these structs contain elements that are used only by libbsc or only by libmsc, besides the elements that are used by both. So at some point I will "split" both of these in two, to have a BSC and an MSC version thereof.
How should we name them?
struct gsm_network (note, if there is a common part, that could still be named 'gsm_network')
--> bsc_network / msc_network looks familiar but the meaning of the name is lost
--> gsm_bsc / gsm_msc
--> osmo_bsc / osmo_msc To me these would be the best and the names are still available, but there are header files named like this and the osmo-bsc binary also has a very similar name. I think I would go for these anyway. +1
--> osmo_gsm_bsc / osmo_gsm_msc As alternative, but the gsm is a bit out of place (particularly in the light of a UMTS MSC).
struct gsm_subscriber_connection
--> bsc_subscriber_connection / msc_subscriber_connection but we could use the opportunity to shorten the name
--> bsc_subscr_conn / msc_subscr_conn I like these best; but add osmo? +1
--> osmo_bsc_subscr_conn / osmo_msc_subscr_conn almost the old length.
Happy shedding, "+1" comments and/or opinions welcome
http://wiki.freeradius.org/contributing/coding-standards
Seems pretty similar to what we do.
Arran Cudbard-Bell a.cudbardb@freeradius.org FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Fri, Nov 11, 2016 at 05:04:00PM -0500, Arran Cudbard-Bell wrote:
not sure how this is related to this thread... anyway:
the most significant differences from freeradius' style is that Osmocom apparently still have 1978 and break lines at 80 chars not 120, and we also prefer a break in 'if (foo && bar) baz();'
We also don't do "Error gotos jump backwards", and apparently also not "Const on the right".
Apart from that it indeed reads like an Osmocom coding style guide.
I like "Const on the right" :) That would have helped me realize what exactly const is tied to a lot sooner than I did.
~N
-
Arran Cudbard-Bell -
Harald Welte -
Neels Hofmeyr