On Wednesday, 26 January 2022 at 23:40:48 UTC, H. S. Teoh wrote:
>
> After many experiences of this, I've come to the conclusion that the convenience of using globals is usually not worth the trouble they cause down the road. I rather "waste" a bit more time writing things the "right" way now, than to waste a LOT of time (and frustration) later trying to debug code riddled with global state.
>
>
> T

I just counted the globals in my GUI IDE (that I developed with C#/Winforms.

34

many set deafault, that can later be modified during function calls, depending on needs at the time.

Without globals, I'd never have bothered ;-)

bool new_compile_needed = true;
public bool new_record_mode = false;
static string custom_tmp = System.IO.Path.GetTempPath() + @"EZ_Compiler\";
string vcvar64 = "";
string vcvar32 = "";
string clang_exe = "clang.exe";
bool Is64Bit;
string clang_xp = @"C:\LLVM\bin\clang-cl.exe";
static string g_cl_c_options = @" /nologo /W4 /GS- /Od";
string g_cl_c_options_new = g_cl_c_options;
static string g_cl_cpp_options = @" /nologo /EHsc /W4 /GS- /Od";
string g_cl_cpp_options_new = g_cl_cpp_options;
static string langversion = @" /langversion:default";
static string g_csc_options = @" /nologo /warn:4 /warnaserror+ /nowarn:168,164 /checked+" + langversion + " /optimize+ /target:exe";
string g_csc_options_new = g_csc_options; // see compile method...
static string g_csc_unsafe_options = @" /nologo /warn:4 /warnaserror+ /nowarn:168,164 /checked+" + langversion + "  /optimize+ /unsafe /target:exe";
string g_csc_unsafe_options_new = g_csc_unsafe_options;
bool vs2019_available = false;
bool vs2015_available = false;
string exeDir = Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);
string current_file = "Current File: (none)";
string dcompiler_mars = "dmd.exe";
string dcompiler_llvm = "ldc2.exe";
string dcompiler = "dmd.exe";
string gocompiler = "go.exe";
string jscompiler = "jrunscript";
string cs_formatter = @"CodeFormatter.exe";
string csprojFileName = custom_tmp + "cs" + ".csproj";
string myDLibDirectory = @" -i -I="  + '\u0022' + "D:\\My Documents\\Dlib"  + '\u0022' + " ";
string Cpp64dll = @"c:\nowheretobefound";
string Cpp32dll = @"c:\nowheretobefound";
string myDocsFolder = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments);
System.Drawing.Color MyBackColor = Color.Black;
System.Drawing.Color MyForeColor = Color.Lavender;

On Thu, Jan 27, 2022 at 12:45:20AM +0000, forkit via Digitalmars-d wrote: [...]
> I just counted the globals in my GUI IDE (that I developed with C#/Winforms.
> 
> 34
> 
> many set deafault, that can later be modified during function calls, depending on needs at the time.
> 
> Without globals, I'd never have bothered ;-)
[...]

Some of your globals are actually global values, like:

> string clang_exe = "clang.exe";
> bool Is64Bit;
> bool vs2019_available = false;
> bool vs2015_available = false;
> string dcompiler_mars = "dmd.exe";
> string dcompiler_llvm = "ldc2.exe";

These I wouldn't be ashamed of declaring as globals, since they ARE globals (in the sense of describing the global environment the program will run in).  You can usually tell these from other globals by whether or not you can make them immutable (though sometimes you may want to keep them mutable if, e.g., you're picking them up from the runtime environment or via program options -- but the idea being that once they're initialized they're effectively immutable).

Others, however, I'd stick into a configuration struct or as member fields in your program's main class, such as:

> bool new_compile_needed = true;
> public bool new_record_mode = false;
> System.Drawing.Color MyBackColor = Color.Black;
> System.Drawing.Color MyForeColor = Color.Lavender;


T

-- 
Do not reason with the unreasonable; you lose by definition.

On Thursday, 27 January 2022 at 01:01:56 UTC, H. S. Teoh wrote:
> On Thu, Jan 27, 2022 at 12:45:20AM +0000, forkit via Digitalmars-d wrote: [...]
>> I just counted the globals in my GUI IDE (that I developed with C#/Winforms.
>> 
>> 34
>> 
>> many set deafault, that can later be modified during function calls, depending on needs at the time.
>> 
>> Without globals, I'd never have bothered ;-)
> [...]
>
> Some of your globals are actually global values, like:
>
>> string clang_exe = "clang.exe";
>> bool Is64Bit;
>> bool vs2019_available = false;
>> bool vs2015_available = false;
>> string dcompiler_mars = "dmd.exe";
>> string dcompiler_llvm = "ldc2.exe";
>
> These I wouldn't be ashamed of declaring as globals, since they ARE globals (in the sense of describing the global environment the program will run in).  You can usually tell these from other globals by whether or not you can make them immutable (though sometimes you may want to keep them mutable if, e.g., you're picking them up from the runtime environment or via program options -- but the idea being that once they're initialized they're effectively immutable).
>
> Others, however, I'd stick into a configuration struct or as member fields in your program's main class, such as:
>
>> bool new_compile_needed = true;
>> public bool new_record_mode = false;
>> System.Drawing.Color MyBackColor = Color.Black;
>> System.Drawing.Color MyForeColor = Color.Lavender;
>
>
> T

The distinction is basically between global state (i.e. things that are mutated often, like "pointer to current item") and globals that are *stated* e.g. "Is logging turned on". The latter is mostly fine with the caveat that it can be indicative of bad architecture (e.g. multiple instances of something like an interpreter is often impossible with any global state at all), the former is extremely bad and can absolutely ruin a program. If you have lots of global state (or even local state whose structure isn't natural) you are doing something wrong.