Code contributions are always welcomed in lf.
If you are going to introduce a new feature, it is best to open an issue first for discussion. If your feature can be implemented as a configuration option please add it to the wiki.
For bug fixes, you can simply send a pull request.
In addition to gofmt
and friends (e.g. go vet, staticcheck, golangci-lint), we have a few conventions:
- Global variables are best avoided except when they are not.
Global variable names are prefixed with
g
as ingFooBar
. Exceptions are variables holding values of environmental variables which are prefixed withenv
as inenvFooBar
and regular expressions which are prefixed withre
as inreFooBar
when they are global. - Type and function names are small case as in
fooBar
since we don't use exporting. - For file name variables,
name
,fname
, orfilename
should refer to the base name of the file as inbaz.txt
, andpath
,fpath
, orfilepath
should refer to the full path of the file as in/foo/bar/baz.txt
. - Run
go fmt
to ensure that files are formatted correctly.
Use the surrounding code as reference when in doubt as usual.
Adding a new option usually requires the following steps:
- Add option name/type to
gOpts
struct inopts.go
- Add default option value to
init
function inopts.go
- Add option evaluation logic to
setExpr.eval
ineval.go
- Implement the option somewhere in the code
- Add option name and its default value to
Quick Reference
andOptions
sections indoc.md
- Run
gen/doc-with-docker.sh
to update the documentation - Commit your changes and send a pull request
Adding a new command usually requires the following steps:
- Add default key if any to
init
function inopts.go
- Add command evaluation logic to
callExpr.eval
ineval.go
- Implement the command somewhere in the code
- Add command name to
gCmdWords
incomplete.go
for tab completion - Add command name to
Quick Reference
andCommands
sections indoc.md
- Optionally, run
gen/doc-with-docker.sh
to update the documentation - Commit your changes and send a pull request
There are two files named os.go
and os_windows.go
for unix and windows specific code respectively.
If you add something to either of these files but not the other, you probably break the build for the other platform.
If your addition works the same in both platforms, your addition probably belongs to main.go
instead.