[lammps-users] code style

hi,
I make some changes in code for myself, now it is nothing worth adding
to the official version, but just in case: is there any style
guideline for LAMMPS code?

I guess not, so I have following questions:

- is it ok to use fstream and family?
- is it ok to use std::string and std::vector.
- I see usually int is used for boolean variables, is it preferred to bool?
- is it ok to use system headers in angle brackets, i.e. #include <stdlib.h>
    (I see that rather "stdlib.h" is used)

Cheers,
Marcin

Hi Marcin. Basically, the best suggestion is to write any new code so
that it has the same "look and feel" as existing LAMMPS code. So, with
that in mind, the answers to your questions are no, no, int is
preferred, and "stdlib.h" is preferred.

We do have an informal "LAMMPS Style Guide" that I'll paste below.
This may help you as you write your code.

Paul

LAMMPS Style Guide

One of the reasons LAMMPS is easy to understand and work on is that
the LAMMPS authors are fairly fanatic about several things:

stylistic C issues: indentation, bracket usage, comment format,
         variable naming conventions, etc
consistency: memory allocation, I/O style, no C++ templates ---
         there are LAMMPS ways to do these things
consistency: when multiple classes do similar things,
         the code fragments are constructed identically

If multiple people contribute to the code, we feel the need to enforce
these kinds of conventions even more strongly.

Adding new features to LAMMPS

There are 2 kinds of features one can add to LAMMPS. The simple kind
is where you are adding a new "style" of something that LAMMPS already
handles (a new pair potential, angle potential, a fix, a temperature,
a new command). The features
themselves may be very complex, but they are isolated and hopefully
require no changes to the rest of LAMMPS.

The 2nd kind is where the new feature does require changes to the rest
of LAMMPS. These can be tricky to implement and require some thought
to consider all the side effects and performance impact. We also feel
it is important to keep the core of LAMMPS simple, so it is not
necessarily desirable to add any feature one can imagine.

So before implementing a new feature of the 2nd kind that you hope to
have included in the main LAMMPS distribution, you should communicate
with Steve Plimpton in order to come to consensus on the following:

a) Should it be done at all?
b) What is the best way to do it that changes LAMMPS the least and
will take side
effects into account?
c) What is the LAMMPS-style of implementing it?

Update the documentation

Making upgrades and bug fixes to LAMMPS is more that editing source
code. It also means updating the doc pages and posting a notice of
the change on the WWW site. For tricky features it often means
creating a new example file or how-to section in the manual. This can
be tedious work, but it is critical in order to keep LAMMPS coherent
and usable.

Hi Marcin. Basically, the best suggestion is to write any new code so
that it has the same "look and feel" as existing LAMMPS code. So, with
that in mind, the answers to your questions are no, no, int is

OK.

preferred, and "stdlib.h" is preferred.

Out of curiosity: why do you use "stdlib.h"? <...> is commonly used
in both C and C++ and recommended by every book or tutorial.

cheers
Marcin

Out of curiosity: why do you use "stdlib.h"? <...> is commonly used
in both C and C++ and recommended by every book or tutorial.

I don't know. Probably just what Steve is used to.

Paul

Marcin,

It also adds the benefit of potentially overloading a built-in include. Say you want to add some extra string functions to enhance functionality. Now you can add a string.h and string.cpp to your already existing directory. string.h would have a header including

#include <string.h>

while everything else would use

#include "string.h"

Currently we try to steer away from the STL, mainly because <complex.h> yields in a far slower treatment of complex number than when using an internal "struct complex { double re, im; }" in combination with operational macros. Maybe this will change in future.

Pieter

It also adds the benefit of potentially overloading a built-in
include. Say you want to add some extra string functions to enhance
functionality. Now you can add a string.h and string.cpp to your
already existing directory. string.h would have a header including

#include <string.h>

while everything else would use

#include "string.h"

This would be a very ugly hack, and that's a reason why <string.h> is
used - to make it clear which headers belong to the program. If you
want to use own string functions, you can include them explicitly,
e.g. #include "mystring.h"

Currently we try to steer away from the STL, mainly because
<complex.h> yields in a far slower treatment of complex number than
when using an internal "struct complex { double re, im; }" in
combination with operational macros. Maybe this will change in future.

I'm missing more string and vector.

thanks,
Marcin

I was also wondering why there are quite a few dangerous C constructs in
the LAMMPS code that could be implemented in a much safer way using the
STL in C++. I am certainly no expert, but fragments like

      char str[128];
      sprintf(str,"Cannot open file %s",file);

seem to open the door for (possibly exploitable) buffer overflows.

  Lutz

Since people build and run LAMMPS themselves, I don't
think of it as a tool for hackers to use to exploit a system.

But if someone wants to use a 10,000 character file name in their input
script that encodes a malicious string overflow, I say send
us the file name and we'll make it a "feature"

Steve