afify / azan (public) (License: MIT) (since 2020-03-08) (hash sha1)
azan is a simple muslim prayers notifier for unix-like systems.
Clone URLs: https://rocketgit.com/user/afify/azan ssh://rocketgit@ssh.rocketgit.com/user/afify/azan git://git.rocketgit.com/user/afify/azan
v0.1 v0.2 master
List of commits:
Subject Hash Author Date (UTC)
[fix] Replace CODE_STYLE with CONTRIBUTING.md be2b91ef8d73aea536bc45446808633561d8afd9 Hassan Afify 2019-09-21 11:14:30
[feat] Edit Makefile, azan.c 538877a4311572caa1ddb88ffd0bac5e0b4379bc Hassan Afify 2019-09-20 12:59:05
[feat] Edit Makefile f41f74a524feb96228eb35a77a336862d5ca958c Hassan Afify 2019-09-19 05:04:00
[feat] Self Calcutation 1be712f454adda33c8a182a4478a3abf5dba6745 Hassan Afify 2019-09-17 08:11:15
[init] Initial Commit 2654768d0412e07cf7aa4b78a41b125aeceab82e Hassan Afify 2019-09-04 01:44:23
Commit be2b91ef8d73aea536bc45446808633561d8afd9 - [fix] Replace CODE_STYLE with CONTRIBUTING.md
- CONTRIBUTING is shown in pull request page in github
- markdown suckless coding style page
Author: Hassan Afify
Author date (UTC): 2019-09-21 11:14
Committer name: Hassan Afify
Committer date (UTC): 2019-09-21 11:14
Parent(s): 538877a4311572caa1ddb88ffd0bac5e0b4379bc
Signing key: 0F6CD1196B2A5658
Tree: 77d1c163fe7188e62b7d1913457b80d8f8aac3a7
File Lines added Lines deleted
CODE_STYLE 0 176
CONTRIBUTING.md 182 0
File CODE_STYLE deleted (index 9677131..0000000)
1 ===============================================================================
2
3 - Suckless code style
4 https://suckless.org/coding_style/
5
6 - Splint (linter)
7 https://splint.org/
8
9 ===============================================================================
10
11 Style
12
13 Note that the following are guidelines and the most important aspect of style is consistency. Strive to keep your style consistent with the project on which you are working. It is up to the project maintainer to take some liberty in the style guidelines.
14 Recommended Reading
15
16 The following contain good information, some of which is repeated below, some of which is contradicted below.
17
18 https://man.openbsd.org/style
19 http://doc.cat-v.org/bell_labs/pikestyle
20 https://www.kernel.org/doc/Documentation/process/coding-style.rst
21
22 File Layout
23
24 Comment with LICENSE and possibly short explanation of file/tool.
25 Headers
26 Macros
27 Types
28 Function declarations:
29 Include variable names.
30 For short files these can be left out.
31 Group/order in logical manner.
32 Global variables.
33 Function definitions in same order as declarations.
34 main
35
36 C Features
37
38 Use C99 without extensions (ISO/IEC 9899:1999).
39 Use POSIX.1-2008:
40 When using gcc define _POSIX_C_SOURCE 200809L.
41 Alternatively define _XOPEN_SOURCE 700.
42 Do not mix declarations and code.
43 Do not use for loop initial declarations.
44 Use /* */ for comments, not //.
45 Variadic macros are acceptable, but remember:
46 __VA_ARGS__ not a named parameter.
47 Arg list cannot be empty.
48
49 Blocks
50
51 All variable declarations at top of block.
52 { on same line preceded by single space (except functions).
53 } on own line unless continuing statement (if else, do while, ...).
54
55 Use block for single statement if inner statement needs a block.
56
57 for (;;) {
58 if (foo) {
59 bar;
60 baz;
61 }
62 }
63
64 Use another branch of the same statement needs a block:
65
66 if (foo) {
67 bar;
68 } else {
69 baz;
70 qux;
71 }
72
73 Leading Whitespace
74
75 Use tabs for indentation and spaces for alignment. This ensures everything will line up independent of tab size. This means:
76
77 No tabs except beginning of line.
78 Use spaces - not tabs - for multiline macros as the indentation level is 0, where the #define began.
79
80 Functions
81
82 Return type and modifiers on own line.
83 Function name and argument list on next line. This allows to grep for function names simply using grep ^functionname(.
84 Opening { on own line (function definitions are a special case of blocks as they cannot be nested).
85 Functions not used outside translation unit should be declared and defined static.
86
87 Example:
88
89 static void
90 usage(void)
91 {
92 eprintf("usage: %s [file ...]\n", argv0);
93 }
94
95 Variables
96
97 Global variables not used outside translation unit should be declared static.
98 In declaration of pointers the * is adjacent to variable name, not type.
99
100 Keywords
101
102 Use a space after if, for, while, switch (they are not function calls).
103 Do not use a space after the opening ( and before the closing ).
104 Preferably use () with sizeof.
105 Do not use a space with sizeof().
106
107 Switch
108
109 Do not indent cases another level.
110 Comment cases that FALLTHROUGH.
111
112 Example:
113
114 switch (value) {
115 case 0: /* FALLTHROUGH */
116 case 1:
117 case 2:
118 break;
119 default:
120 break;
121 }
122
123 Headers
124
125 Place system/libc headers first in alphabetical order.
126 If headers must be included in a specific order add a comment to explain.
127 Place local headers after an empty line.
128 When writing and using local headers.
129 Try to avoid cyclic header inclusion dependencies.
130 Instead ensure they are included where and when they are needed.
131 Read https://talks.golang.org/2012/splash.article#TOC_5.
132 Read http://plan9.bell-labs.com/sys/doc/comp.html
133
134 User Defined Types
135
136 Do not use type_t naming (it is reserved for POSIX and less readable).
137 Typedef opaque structs.
138 Do not typedef builtin types.
139 Use CamelCase for typedef'd types.
140
141 Line Length
142
143 Keep lines to reasonable length (max 79 characters).
144
145 Tests and Boolean Values
146
147 Do not use C99 bool types (stick to integer types).
148 Otherwise use compound assignment and tests unless the line grows too long:
149
150 if (!(p = malloc(sizeof(*p))))
151 hcf();
152
153 Handling Errors
154
155 When functions return -1 for error test against 0 not -1:
156
157 if (func() < 0)
158 hcf();
159
160 Use goto to unwind and cleanup when necessary instead of multiple nested levels.
161 return or exit early on failures instead of multiple nested levels.
162 Unreachable code should have a NOTREACHED comment.
163 Think long and hard on whether or not you should cleanup on fatal errors. For simple "one-shot" programs (not daemons) it can be OK to not free memory. It is advised to cleanup temporary files however.
164
165 Enums and #define
166
167 Use enums for values that are grouped semantically and #define otherwise:
168
169 #define MAXSZ 4096
170 #define MAGIC1 0xdeadbeef
171
172 enum {
173 DIRECTION_X,
174 DIRECTION_Y,
175 DIRECTION_Z
176 };
File CONTRIBUTING.md added (mode: 100644) (index 0000000..65b379f)
1 Contributing to Azan
2 ====================
3
4 Patches are welcome in whatever form.
5 Discussions about patches happen on the vim-dev maillist.
6 If you create a pull request on GitHub it will be
7 forwarded to the vim-dev maillist. You can also send your patch there
8 directly. In that case an attachment with a unified diff format is preferred.
9 Information about the maillist can be found [on the Vim website].
10
11 [on the Vim website]: http://www.vim.org/maillist.php#vim-dev
12
13 Static code analyzers
14 ---------------------
15 - [splint] - A tool for statically checking C programs for security vulnerabilities and coding mistakes
16 - [valgrind] - Tool to help find memory-management problems in programs.
17
18 Used Compiler
19 ------------
20 - TCC — Tiny C Compiler.
21
22 **Other C Compilers**
23 - **GCC** is the virus which has spread into nearly every Linux distribution and has added its language extensions to be not easily replacable. As of 2016 it is now written in C++ and so complete suck. Why can't a compiler just be a simple binary doing its work instead of adding path dependencies deep into the system?
24 - **Clang** is written in C++. If you don't believe that it sucks, try to build clang by hand.
25
26 C Styleguide
27 ------------
28 [Suckless code style]
29
30 **Style**
31 Note that the following are guidelines and the most important aspect of style is consistency. Strive to keep your style consistent with the project on which you are working. It is up to the project maintainer to take some liberty in the style guidelines.
32
33 **Recommended Reading**
34 The following contain good information, some of which is repeated below, some of which is contradicted below.
35 - https://man.openbsd.org/style
36 - http://doc.cat-v.org/bell\_labs/pikestyle
37 - https://www.kernel.org/doc/Documentation/process/coding-style.rst
38
39 **File Layout**
40 - Comment with LICENSE and possibly short explanation of file/tool.
41 - Headers
42 - Macros
43 - Types
44 - Function declarations:
45 - Include variable names.
46 - For short files these can be left out.
47 - Group/order in logical manner.
48 - Global variables.
49 - Function definitions in same order as declarations.
50 - `main`
51
52 **C Features**
53 - Use C99 without extensions (ISO/IEC 9899:1999).
54 - Use POSIX.1-2008:
55 - When using gcc define `_POSIX_C_SOURCE 200809L`.
56 - Alternatively define `_XOPEN_SOURCE 700`.
57 - Do not mix declarations and code.
58 - Do not use for loop initial declarations.
59 - Use `/* */` for comments, not `//`.
60 - Variadic macros are acceptable, but remember:
61 - `__VA_ARGS__` not a named parameter.
62 - Arg list cannot be empty.
63
64 **Blocks**
65 - All variable declarations at top of block.
66 - `{` on same line preceded by single space (except functions).
67 - `}` on own line unless continuing statement (`if` `else`, `do while`, ...).
68
69 Use block for single statement if inner statement needs a block.
70 ```c
71 for (;;) {
72 if (foo) {
73 bar;
74 baz;
75 }
76 }
77 ```
78 Use another branch of the same statement needs a block:
79 ```c
80 if (foo) {
81 bar;
82 } else {
83 baz;
84 qux;
85 }
86 ```
87
88 **Leading Whitespace**
89 - Use tabs for indentation and spaces for alignment. This ensures everything will line up independent of tab size. This means:
90 - No tabs except beginning of line.
91 - Use spaces - not tabs - for multiline macros as the indentation level is 0, where the `#define` began.
92
93 **Functions**
94 - Return type and modifiers on own line.
95 - Function name and argument list on next line. This allows to grep for function names simply using `grep ^functionname(`.
96 - Opening { on own line (function definitions are a special case of blocks as they cannot be nested).
97 - Functions not used outside translation unit should be declared and defined `static`.
98 Example:
99 ```c
100 static void
101 usage(void)
102 {
103 eprintf("usage: %s [file ...]\n", argv0);
104 }
105 ```
106
107 **Variables**
108 - Global variables not used outside translation unit should be declared `static`.
109 - In declaration of pointers the `*` is adjacent to variable name, not type.
110
111 **Keywords**
112 - Use a space after if, for, while, switch (they are not function calls).
113 - Do not use a space after the opening ( and before the closing ).
114 - Preferably use `()` with `sizeof`.
115 - Do not use a space with `sizeof()`.
116
117 **Switch**
118 - Do not indent cases another level.
119 - Comment cases that FALLTHROUGH.
120 Example:
121 ```c
122 switch (value) {
123 case 0: /* FALLTHROUGH */
124 case 1:
125 case 2:
126 break;
127 default:
128 break;
129 }
130 ```
131
132 **Headers**
133 - Place system/libc headers first in alphabetical order.
134 - If headers must be included in a specific order add a comment to explain.
135 - Place local headers after an empty line.
136 - When writing and using local headers.
137 - Try to avoid cyclic header inclusion dependencies.
138 - Instead ensure they are included where and when they are needed.
139 - Read https://talks.golang.org/2012/splash.article#TOC\_5.
140 - Read http://plan9.bell-labs.com/sys/doc/comp.html
141
142 **User Defined Types**
143 - Do not use `type\_t` naming (it is reserved for POSIX and less readable).
144 - Typedef opaque structs.
145 - Do not `typedef` builtin types.
146 - Use `CamelCase` for typedef'd types.
147
148 **Line Length**
149 - Keep lines to reasonable length (max 79 characters).
150
151 **Tests and Boolean Values**
152 - Do not use C99 `bool` types (stick to integer types).
153 - Otherwise use compound assignment and tests unless the line grows too long:
154 ```c
155 if (!(p = malloc(sizeof(\*p))))
156 hcf();
157 ```
158 **Handling Errors**
159 - When functions `return -1` for error test against `0` not `-1`:
160 ```c
161 if (func() < 0)
162 hcf();
163 ```
164 - Use goto to unwind and cleanup when necessary instead of multiple nested levels.
165 - `return` or `exit` early on failures instead of multiple nested levels.
166 - Unreachable code should have a NOTREACHED comment.
167 - Think long and hard on whether or not you should cleanup on fatal errors. For simple "one-shot" programs (not daemons) it can be OK to not free memory. It is advised to cleanup temporary files however.
168
169 **Enums and #define**
170 Use enums for values that are grouped semantically and `#define` otherwise:
171 ```c
172 #define MAXSZ 4096
173 #define MAGIC1 0xdeadbeef
174 enum {
175 DIRECTION_X,
176 DIRECTION_Y,
177 DIRECTION_Z
178 };
179 ```
180 [Suckless code style]: <https://suckless.org/coding_style>
181 [splint]: <https://splint.org>
182 [valgrind]: <https://http://www.valgrind.org>
Hints:
Before first commit, do not forget to setup your git environment:
git config --global user.name "your_name_here"
git config --global user.email "your@email_here"

Clone this repository using HTTP(S):
git clone https://rocketgit.com/user/afify/azan

Clone this repository using ssh (do not forget to upload a key first):
git clone ssh://rocketgit@ssh.rocketgit.com/user/afify/azan

Clone this repository using git:
git clone git://git.rocketgit.com/user/afify/azan

You are allowed to anonymously push to this repository.
This means that your pushed commits will automatically be transformed into a merge request:
... clone the repository ...
... make some changes and some commits ...
git push origin main