authorgravatar for git@vexu.euVeikka Tuominen <git@vexu.eu> 2020-05-13 19:28:14+03:00
committergravatar for noreply@github.comGitHub <noreply@github.com> 2020-05-13 19:28:14+03:00
log4b898893e21fc644c4e7a163232e5e98631640d6
treece6afa5a2c74d45103a67b25cccb2ef229f12288
parent118db892bea5222a509a9f91abe560b52a5f08eb
parent3a397795be1c0219a3a0d96082ee7d4eeddbfa7a
signaturebadge-question-mark Signed by PGP key 4AEE18F83AFDEB23

Merge pull request #5254 from ifreund/top-level-struct-file-names

Apply naming conventions of structs to files

1 files changed, 8 insertions(+), 0 deletions(-)

doc/langref.html.in+8
......@@ -9988,6 +9988,13 @@ coding style.
99889988 conventions.
99899989 </p>
99909990 <p>
9991 File names fall into two categories: types and namespaces. If the file
9992 (implicity a struct) has top level fields, it should be named like any
9993 other struct with fields using {#syntax#}TitleCase{#endsyntax#}. Otherwise,
9994 it should use {#syntax#}snake_case{#endsyntax#}. Directory names should be
9995 {#syntax#}snake_case{#endsyntax#}.
9996 </p>
9997 <p>
99919998 These are general rules of thumb; if it makes sense to do something different,
99929999 do what makes sense. For example, if there is an established convention such as
999310000 {#syntax#}ENOENT{#endsyntax#}, follow the established convention.
......@@ -9996,6 +10003,7 @@ coding style.
999610003 {#header_open|Examples#}
999710004 {#code_begin|syntax#}
999810005const namespace_name = @import("dir_name/file_name.zig");
10006const TypeName = @import("dir_name/TypeName.zig");
999910007var global_var: i32 = undefined;
1000010008const const_name = 42;
1000110009const primitive_type_alias = f32;