kopia lustrzana https://github.com/Hamlib/Hamlib
Add preferred astylerc configuration
Astyle is a code formatting utility that can quickly reformat a source file based on the settings of its configuration file. The added configuration file will format to a style mostly consistent with the Linux Kernel Style guide: https://www.kernel.org/doc/Documentation/CodingStyle While conformance to this document is not the goal, it supplies a reasonable set of guidelines to be used in Hamlib.libusb-1-0
rodzic
c26b893498
commit
022ba0f48b
|
@ -6,6 +6,7 @@
|
||||||
*.o
|
*.o
|
||||||
*.lo
|
*.lo
|
||||||
*.la
|
*.la
|
||||||
|
*.orig
|
||||||
*.swp
|
*.swp
|
||||||
Makefile
|
Makefile
|
||||||
Makefile.in
|
Makefile.in
|
||||||
|
|
|
@ -542,17 +542,29 @@ readability. Align closing braces with the opening block's keyword. In
|
||||||
function definitions put the opening brace on its own line under the
|
function definitions put the opening brace on its own line under the
|
||||||
definition's parameter line.
|
definition's parameter line.
|
||||||
|
|
||||||
Hamlib source code is no place for an entry into the obsfucated C contest!
|
A configuration file for the Artistic Style (http://astyle.sourceforge.net/)
|
||||||
|
utility can be found in the scripts directory. The settings it provides should
|
||||||
|
conform reasonably close to the Linux style guide referenced above. This file
|
||||||
|
can be copied to $HOME/.astylerc where it will be used as the default
|
||||||
|
configuration. If you already have an existing .astylerc, passing
|
||||||
|
|
||||||
|
--options=/path/to/hamlib/scripts/astylerc
|
||||||
|
|
||||||
|
will use this file as the configuration for formatting. Consider using this
|
||||||
|
utility whenever working on a given C source file in Hamlib.
|
||||||
|
|
||||||
|
Hamlib source code is no place for an entry into the obfuscated C contest!
|
||||||
Many of us are hobbyists and write this for fun. Easy to read and
|
Many of us are hobbyists and write this for fun. Easy to read and
|
||||||
understand logic is preferred over a clever solution. If your solution must
|
understand logic is preferred over a clever solution. If your solution must
|
||||||
be written in a clever fashion, please document it well in your comments.
|
be written in a clever fashion, please document it well in your comments.
|
||||||
|
|
||||||
Any header files included from the hamlib/ directory should be enclosed
|
Any header files included from the hamlib/ directory should be enclosed in <>:
|
||||||
in <>:
|
|
||||||
#include <hamlib/rig.h> # Per GNU GCC documentation
|
#include <hamlib/rig.h> # Per GNU GCC documentation
|
||||||
|
|
||||||
Other included header files (backend and rig specific headers) should be
|
Other included header files (backend and rig specific headers) should be
|
||||||
enclosed in "":
|
enclosed in "":
|
||||||
|
|
||||||
#include "yaesu.h"
|
#include "yaesu.h"
|
||||||
|
|
||||||
Contributed code should always keep the source base in a compilable state,
|
Contributed code should always keep the source base in a compilable state,
|
||||||
|
@ -581,6 +593,7 @@ Hamlib should also compile with the following common compilers:
|
||||||
|
|
||||||
Portability issues to watch:
|
Portability issues to watch:
|
||||||
|
|
||||||
|
* C99 is probably (in 2016) a reasonable target
|
||||||
* little vs. big endian systems (use shifts or adhoc functions)
|
* little vs. big endian systems (use shifts or adhoc functions)
|
||||||
* 64 bit int: avoid them in API
|
* 64 bit int: avoid them in API
|
||||||
* printf/scanf of 64bit int: use PRIll (cast value to int64_t) and SCNll
|
* printf/scanf of 64bit int: use PRIll (cast value to int64_t) and SCNll
|
||||||
|
@ -672,6 +685,9 @@ big, you can send it as a compressed attachment.
|
||||||
|
|
||||||
8.3.1 Changelog
|
8.3.1 Changelog
|
||||||
|
|
||||||
|
A ChangeLog file is no longer manually maintained. At some point it may be
|
||||||
|
automatically generated from the Git commit log for source tarballs.
|
||||||
|
|
||||||
Simply summarize your changes when the files are committed to Git or, if
|
Simply summarize your changes when the files are committed to Git or, if
|
||||||
providing patches to the mailing list, provide a summary so the uploader can
|
providing patches to the mailing list, provide a summary so the uploader can
|
||||||
include it in the commit message which will show in the commit log (Git
|
include it in the commit message which will show in the commit log (Git
|
||||||
|
|
|
@ -0,0 +1,32 @@
|
||||||
|
# astylerc--custom options for astyle
|
||||||
|
# Intended to follow the Linux style guide as closely as possible:
|
||||||
|
# https://www.kernel.org/doc/Documentation/CodingStyle
|
||||||
|
|
||||||
|
# Linux kernel style formatting/indenting.
|
||||||
|
style=linux
|
||||||
|
|
||||||
|
# Use tabs with a width of 8 spaces.
|
||||||
|
indent=force-tab=8
|
||||||
|
|
||||||
|
# Pad empty lines around header blocks (e.g. 'if', 'for', 'while'...).
|
||||||
|
break-blocks
|
||||||
|
|
||||||
|
# Remove extra space padding around parenthesis on the inside and outside.
|
||||||
|
unpad-paren
|
||||||
|
|
||||||
|
# Insert space padding around operators.
|
||||||
|
pad-oper
|
||||||
|
|
||||||
|
# Insert space padding after paren headers only (e.g. 'if', 'for', 'while'...).
|
||||||
|
pad-header
|
||||||
|
|
||||||
|
# Attach a pointer operator (*) to name (name) and reference operator (&)
|
||||||
|
# to type (type).
|
||||||
|
align-pointer=name
|
||||||
|
align-reference=type
|
||||||
|
|
||||||
|
# Don't break one-line blocks.
|
||||||
|
keep-one-line-blocks
|
||||||
|
|
||||||
|
# Don't break complex statements and multiple statements residing on a single line.
|
||||||
|
keep-one-line-statements
|
Ładowanie…
Reference in New Issue