Coding Advices to Contributors

We do not require in the development of code for DP to follow specific coding rules, such as alphabetic order conventions and so on.

But we reccommend you to follow a standard "code structuring" policy and philosophy, such as to have a "structured" code, as first stated by Kernighan and Ritchie. That is, of the whole amount of work to be done, try to individuate the different, separate, elemental, small tasks composing it, and code them in separate, small (normally no more than 20~30 source lines), elemental routines and functions which can be later reused as black boxes for other, maybe completely different, purposes. Then write the higher level routines, which represent tasks of a more specialized and less elemental degree, and which do some, no more than 10, actions, calling the low level routines. And go on, up to the higly specialized main or high level routines, in a pyramidal hierarchycal structure. Organize "homogenous" subroutines and functions in files containing them conveniently. Each file should be thought as the unit that contains all the routines that belong ideally to a "library" of tasks. Such as the file could represent the development unit of a programmer who ideally can work on only one file at once, without the need to open and study many other files of the code.

Please, avoid to code very long subroutines and functions of hundreds of source lines, very much specialized, of difficult mantainance, readibility, etc. And try to write as many small subroutines and functions as you can. This would allow the code to remain simple, readable without the need of a complex navigation inside, with each subroutine understandable in itself, without the need to open the called functions and subroutines; or to open distant located subroutines from the part under analysis. Each developer could work on the part he is interested in, treating the rest as black boxes, without correlation with other parallel developments. Ideally, a structured code is a composition of many independent parts, rather than a monolith with heavy correlations among all the parts composing it. The code structuring is also the best way to have reusable code, elemental actions and small functions being much more general and universal than heavy, specialized routines.

We would also like to have an object-oriented DP code. But as far as we tried, we didn't succeed to individuate the right, well conceived objects for a TDDFT PW code, and we were obliged to many U-turns to restablish an acceptable situation. Objects are so far introduced and used only as simple structures in order to join data in bunches and avoid long argument passing lists when calling subroutines and functions. We still are waiting for acceptable and working solutions toward an effectively object-oriented direction. Advices along this direction are welcome.

Finally, the code is already written not only in Fortran, not homogenous for what concerns languages. And we encourage you to write in the language you consider more appropriated for the part you are considering, provided that the language disposes of well spread compilers or intepreters, such as it is not a problem for other users to use it. And these are at the moment C, Fortran, Java, Perl and Python. There is also the consideration that object-oriented and dishomogenoues languages codes are mutually exclusive.