Coding Patterns - gerhardol/gitextensions GitHub Wiki

This document aims to provide guildelines related to coding patterns specific to this project.

When creating a git command in code, don't use strings. Use GitArgumentBuilder. It has special features to help create the right arguments for a git command.

• It will add -c arguments when needed based on which command is used. You can add config items also.
• It allows you to create optional arguments by writing an argument like this {condition, "Argument string"}. If condition is true, argument string is added. You can include an "else" value too.
• It provides for Git Options when needed.

An example:

var args = new GitArgumentBuilder("log")
{
    "--pretty=\"format:%G?\"",
    "-1",
    revision.Guid
};

string gpg = module.RunGitCmd(args);

Make use of ISetting:

private static readonly SettingsPath SettingsPath = new AppSettingsPath("SettingsGroup");

public static ISetting<ValueType> SettingName { get; } = Setting.Create(SettingsPath, nameof(SettingName), defaultValue);

Add a regarding testcase to tests/app/UnitTests/GitCommands.Tests/Settings/AppSettingsTests.cs:

yield return (properties[nameof(AppSettings.SettingName)], defaultValue, isNotNullable, isISetting);

Localisation is performed via translation files having .xlf extension. Changes should never be done manually to these files.

.xlf files do not need to be manually modified when adding strings, but you need to update the .xlffiles when you change strings to see the new strings in the build. It is formally not required to submit the changes as the English .xlf is generated by TranslationApp and then uploaded to Transifex when a release is generated see Prepare a release. Other languages are then populated via the Transifex site by our team of translators before being downloaded. It may be required to run the TranslationApp to review a PR.

Errors from external operations like calling other executables (e.g. git) or accessing the filesystem or the network shall be wrapped in an ExternalOperationException in order to distinguish them from real bugs.

Do not swallow errors, e.g. no empty catch clauses!

If an exception is really of very little interest to the user, use Trace.WriteLine to record the error message. (It is displayed in the GE's Output History and Sysinternals DebugView.) Do not write to the Console.