Association Subscribers Manager and Open source stuffs

To content | To menu | To search

Tag - coding

Entries feed - Comments feed

Saturday 2 February 2008

SGNCC - Slack-Get Naming Convention Compliant : the new slack-get's naming convention document

By Arnaud Dupuis on Saturday 2 February 2008, 17:35 - slack-get

Document purpose :

The purpose of this document is to "standardize" slack-get development by imposing a naming convention for both (but not only) : slack-get clients, sg_daemon, all Perl modules and the C++ library.
This include of course, all plug-in which can be released in the futur.

Vocabulary :

In the future, we will refers to the slack-get naming convention as :
SGNC: for Slack-Get Naming Convention.

Additionally, we will refers to SGNC compliant code as SGNCC (SGNC Compliant).

Scope of the SGNC :

All the code released under the "slack-get development team" label must be SGNC compliant (SGNCC).
More generally, all code released and packaged with slack-get must be (and will be) SGNCC.
The SGNC apply to all API visible method names. Every methods in a class or bundle must be SGNCC. By extension to this principle all methods in the sg_daemon, slack-get and the upcoming slack-get GUI have to be SGNCC.
All script released and packaged with slack-get should be SGNCC too. But in order to not slow down some developments it is acceptable to keep not SGNCC code in the branch/ SVN tree. If released with slack-get, this code will be optional at building and installation time. It will also be released in a different package.

Rules of SGNC :

We refer to functions and methods as the same generic term of "method".
The SGNC consist in the following 3 simple programing rules :
  1. a method name consist of lower case, English words where space are replaced with underscores ;
  2. if the method name is conflicting with Perl or C++ built-in function or language syntax, change the case of the first letter to upper  case.
  3. if a conflict was solved according to rule 2), and if the name conflicts with only one of the supported languages (Perl and C++), add a wrapper method around the renamed one, in order to comply with the rule 1).


The slack-get development team

no comment

Wednesday 30 January 2008

slack-get API review

By Arnaud Dupuis on Wednesday 30 January 2008, 08:39 - slack-get

Hi,

Back from holidays, I started to work again on slack-get by a huge code review and documentation updates of the API.
My current contract had an impact on this process since it consists in extending the NMIS tool. This tool is really great and useful like no other ones when it comes to network monitoring tasks.
But this tool also have an important flaw : its API is a real mess. It consist of a main script of 7000 code lines and few modules (around 10) totally undocumented !
My job is currently to run into this code, understand it (hopefully it's not too hard to guess) and find a way to add something like a plug-in system to it. Unfortunately, all NMIS modules exports all their functions in the calling script's namespace...
So I choose to have a different naming convention than the one in NMIS for plug-in's methods name... And their is no naming convention in NMIS...

And I sadly saw that it was exactly the same  with slack-get Perl API... So starting today I will change that and tag along with the following naming convention :
  1. a method name consist of English words where space are replaced with underscores ;
  2. if the name is conflicting with Perl or C++ built-in function or language syntax, change the case of the first letter to upper  case.
  3. if a conflict was solved according to rule 2), and if the name do not conflict with the other language, add a wrapper method around the renamed one, in order to comply with the rule 1).
Boring work but I deserve to do it...

Arnaud Dupuis

one comment