I was slow to realize the benefits of it for C++. Recently, I needed to wrap a complicated templated class (CUDA Thrust host_vector and some others), and I asked the GitHub Copilot chat to generate wrappers using the private-implementation pattern (pimpl pattern). It gave me a fantastic start to it, throwing in the right include files. It did not make wrappers for 100% of it, but I was able to fill in the missing pieces easily enough. In fact, its inline suggestions in Visual Studio 2022 often saved me a whole bunch of typing. Once it saw that I was repeating a pattern (wrapping a class using the pimpl pattern), the inline suggestions saved me typing boiler-plate stuff for levels of indirection and such. Other useful things I have asked it are to write me a CUDA algorithm that does something pretty specific. Sooo useful. However, the Windows Copilot (free) seems similarly capable as long as it does not need to see your code. GitHub Copilot knows how you like to name your identifiers (m_width_meters vs m_width_pixels, for example). Those little touches have got me hooked. If I am confused about how to invoke a C++ standard-library function, I ask for an example program. Am I twice as productive? No. But I'm hooked.

I have found that for refactoring and debugging, it helps to have all of the source code in one solution or cmake project. That way, the tools (VS, Resharper, others) can semantically "see" and analyze everything together. Once you go across boundaries like NuGet packages, some of that convenience is lost.

These days, I am not as wed to object-oriented design as I used to be. However, I focus heavily on the S.O.L.I.D. principles whether in stand-alone functions or class/module design. Those principles pay dividends even if code never gets reused. I have also found that new requirements come out of left field sometimes, and having S.O.L.I.D. code makes it easier to adapt or reuse things that were never intended to be reused.

The question about "why decaf?" comes up all the time at my work. The answer is simple: we like drinking coffee and it has health benefits (only without milk or sugar according to the science--see nutritionfacts.org). You can get the same amount of caffeine with a pill that costs a penny, so why drink espresso at all if not for the pleasure and health benefits? Decaf makes as much sense as regular, seems to me.

We focus heavily on code reuse, so DLL boundaries are focused on assembly dependencies, not on related tasks or something. For example, we have a large C# DLL called Core that has no third-party dependencies, so a bunch of stuff is lumped together that are not related. On the other hand, we wrap a third-party device DLL, so that wrapper is in a DLL by itself due to the extra assembly dependency. The result is that we have a enough DLLs to allow for DLL-boundary code reuse, but we do not further subdivide them based on related source code. The compromise prevents us from having too many DLLs. We have about 40, each with different assembly dependencies.

Georgia 11. I already know that I'm committing some crime by using a proportional font for coding, but I'm not stuck in the 1980s.

At least someone is *trying* to handle/report errors. Better than ignoring them.

Good thread for this electron season.

var listOfThreeListsOfByteArrayRowThenColumnOfOneScaledColorChannel = new List<byte[,]>[3];
listOfThreeListsOfByteArrayRowThenColumnOfOneScaledColorChannel[0] = new List<byte[,]>();
listOfThreeListsOfByteArrayRowThenColumnOfOneScaledColorChannel[1] = new List<byte[,]>();
listOfThreeListsOfByteArrayRowThenColumnOfOneScaledColorChannel[2] = new List<byte[,]>();

I just renamed someone's identifier that was called 'data' to be more self documenting: 'listOfThreeListsOfByteArrayRowThenColumnOfOneScaledColorChannel' I should either be promoted or fired for that. I'm not sure which. Can anyone top that for self-documenting identifier names?

BioDefense on iPhone

I'll second the suggestion to use Search Everything for all but content searches. I've never seen a slow-down in the indexing, and it's basically instantaneous filtering-type searching with wildcards. It handles filters that have thousands of results just fine. I've used it for several years with not a single issue. http://www.voidtools.com/download.php

I've seen so many developers (especially newer ones) obsess over code syntactic readability, but I have found that I can get used to any style. My mental focus is mainly on code design (class, method, static definitions, etc.) more than the syntactic details. I would write try { myField = new Field(...); } catch { report error } because at a design level, it is only one logical statement. The error handing in this case is related to that statement, so I kept it on the same line. If it takes two steps to do something, I'll spread out the code to more lines: try { myField = new Field(...); myField.Event += event handler; } catch { report error }; Still, my focus is not on seeing (or obsessing over) curly braces, but rather on seeing the logical steps going on. I want the curly braces to drift into the background. I'm a contractor, so I match the style used by each employer, and I adapt pretty quickly to whatever they do, no matter how illogical. I don't let myself obsess over syntax, so once I get used to a style, those curly braces just disappear from my view, leaving the logical structure. When code has inconsistent syntax (such as each developer using a unique style), I can't help but notice the syntax, distracting me from higher-level design. Thus, the most important thing for me is CONSISTENCY.

BRU has been solid and great for years. You have to upgrade to use it across a network, though.

I stumbled on a nice trick when using Resharper with C#: If you have non-public methods in an effort to avoid those long methods, make the helper methods static and pass in all needed information through parameters. It keeps it clear that the helper methods are not accessing field variables. I think Resharper recommended this trick when it recognized that a helper method did not access local fields, and I adopted it as my general strategy.

In college (late 80s), I was all about lined up braces (choice 2). However, once I stopped hacking so much, and instead started writing better planned-out code, readability of individual code statements became less important to me than readability of class-level design (function prototypes, member variables). Thus, I developed a consistent style of cramming code together. No empty lines unless it's temporary (fill in the blank later type of thing), and no newlines for braces unless there are two or more statements. Here is an extreme example of a one-function class. Assume that the set is one statement and the get is one statement (if more than one, I split it out like choice 1 in the original posting). namespace abc { class xyz { public string ToolTip { set { do; } get { return something; } } } } Basically, once I write it, I don't want to have to look at the implementation of it again. Sometimes during development of longer functions, I'll spread it out. Then, when it's all correct and tested, I shrink it down according to the one-statement rules. I'm always consistent with the {} usage. Of course, I couldn't pull off this crammed style in a typical team environment because people wouldn't trust each other to get it right the first time. If you did trust each other, it could work in that environment. Dale P.S. For the last two years, I wrote VB.Net code and got totally used to spread-out code. Experienced programmers can get used to any consistent style, I think. Newer programmers are typically more insistent on their own unique style. -- modified at 9:46 Thursday 17th May, 2007