Curly Brace Coder

I've noticed time and again developers who don't quite grok what value there is to using Git for revision control of source. I've witnessed even more developers twist themselves in knots trying to explain and/or defend using Git, or rail against it proclaiming, "What's the big deal? I don't get it...". Here then is my take on Git in a nutshell: The point of GIT, and what it's trying to solve basically boils down to this: 1) The repository lives on your local OS file system. What that offers is a way to version control anything you want (more on text vs. binary ahead), and can sneaker net the entire repository with the copy command without losing version information of changes ! All of the deltas and history are all contained in a nice neat folder named .git. 2) You can also (instead of sneaker net) host the source code on a remote server, which allows anyone with the necessary privileges to pull or commit changes. 3) You can apply filters on what files

I've now seen several articles that discuss converting a Console app to a Windows app without addressing outstanding issues that need to be addressed. I thought this would be a good place to do so. But first, why did the authors intend to do this? Seems that when starting up a Console app, even if you try to hide the Console window, there is a brief (and annoying) flash. I suggested the following: Apparently, there is a warning in the Microsoft docs suggesting to avoid GetConsoleWindow() in that this wont work in future version in Remote Desktop/Terminal Services.  I would counter that if that's the concern, converting to a Windows app makes things worse because stdin , stdout and stderr are closed, which make the application interaction impossible. So let's follow this then and see what issues need to be addressed if we pursue this course of action: 1)   stdin ,   stdout   and   stderr   are sent to   devnull . This isn't just a question of command line parsing, many

  I've seen a rather disturbing trend over the last 20 years, and no where is it more personified, symbolized and epitomized than in the plethora of developer Q&A and code sample websites that now dominate the software engineer landscape. They seem to fall into two camps if you will: A true to form reputation system commanded by experts utilizing a reputation system that rewards users for contributing high-quality content to the site such as Stack Overflow. A more "big tent" community-driven website that focuses on providing resources and tools for software developers, which includes a vast library of articles, tutorials, and code samples that cover a wide range of programming languages and platforms. The former tends to focus less on complete samples, but holds both the authors of the questions, and the answers feet to the fire as it were for quality and being on target. The downside of such a system is that you need both talent and a rather thick skin to play, thoug

I've noticed a very disturbing trend that continues to repeat whenever the topic and task of code reviews come up. So much (too much?) attention is paid to the "rules" of combat, everything from the proper etiquette of code reviews to the agreed upon coding standards de jour. Too little  attention, to my mind, is paid to the skill set required to actually perform a proper code review. Let me illustrate with an example. Client 'X' goes through great pains and kerfuffle to define a coding standard. Curly braces go here (hence the name of this blog). Variable are names this way. To comment or not to comment, that is the question, and so on, and so forth. I submit some code for a pull request. I get back... line noise. Kind of like the automated resume readers that scan for keywords. Rule matching, except done poorly by humans. Did you actually look at the code, or at the Git Diff tool?  Look at the code? Are you out of your mind? I'm busy, I have real  work to do

When you work for as long as I have and on as many projects and software problems as I have encountered, it stands to reason that you will tend to end up working with other bright engineers. I have had the pleasure of working with developers on a great many applications that I have not only been proud to attach my name to, but that I am pleased to say are still out there in the wild working as expected, performing as designed, and making clients quite happy in the process. When it comes to troubleshooting systems... I am sometimes really surprised where things can take a turn. I have often heard this described as a special skill set, something that some are better adept at than others. The more cynical folks I have met will ascribe it to a darker missive, one where developers are either lazy, incompetent, or simply blame the first thing they don't understand. I don't believe its either some wizard's skill attained climbing the magic mountain, nor will I trash those w

You are a seasoned C++ applications or embedded programmer, and you need to access an integer bitfield as a set of specific bits. You know how to do this: union   myUnion { unsigned   int   info ; struct { unsigned   int   flag1   :   1 ;   // bit 0 unsigned   int   flag2   :   1 ;   // bit 1 unsigned   int   flag3   :   1 ;   // bit 2 unsigned   int   flag4   :   1 ;   // bit 3 unsigned   int   flag5   :   1 ;   // bit 4 unsigned   int   flag6   :   1 ;   // bit 5 // . // . // . unsigned   int   flag31   :   1 ;   // bit 31 }; }; Supposing, however, you are a C#/.NET programmer. What do you do then? There is no provision or direct support in the language to do this. What tools do you have at your disposal? Well, you do have: [ StructLayout ( LayoutKind . Explicit, Size  =   1 , CharSet  =   CharSet . Ansi)] That will give you the ability to control the byte packing. You also have: [ FieldOffset ( x )]             Where: x