I was born with a built-in "digital" computer, which to this day, is still affective for counting, adding and subtracting numbers up to ten, and multiplying by nine. I guess technically this is the oldest computer my parents built.

In general, a reason NOT to use Hungarian Notation is that it keeps the programmer from abstracting the data from the type. In fact, it does the opposite. For UI controls, the variables are NOT abstract from the control; they are intrinsically linked. They are one in the same. There's nothing to make more abstract from a variable "okButton." A button is a button, but an Uint16 could be just about anything. So, I say using the Hungarian-like notation for specific control types makes sense.

I will paraphrase my doctor with whom I check-in every year or so. I drink a LOT of coffee, but he says that if it's not causing me problems (stomach, sleep, etc.) I can pretty much have as much as I want. It's sugary drinks that are a problem. (I happen to have stopped adding sugar a couple of years ago, and I don't drink sugary drinks.) It's soda that's the real killer, and this includes fruit juices, bottled teas, energy drinks, etc. which are ALL sugar (and it's doesn't matter where that sugar comes from - cane, corn, etc...) Coffee: Good Mt. Dew: Bad Just my personal soapbox....

I have thought a LOT about the backup thing. Until very recently (using Windows XP), I used Microsoft's SyncToy, which is a free download part of their "Power Toys." It's very easy to use, configurable, and straight forward. I setup a weekly Outlook reminder to plug-in my external harddrive and run the sync. Here are some thoughts: I keep the harddrive unplugged from the mains and my PC unless I use it for the backup. That way, in case there is a power surge, etc., the PC may be fried, but not the HDD. I do not bother backing up the whole drive, making "restore" images, etc. I figure if something goes wrong with the drive, OS, etc., just get a new drive (or do a re-format) and start fresh with a clean copy of Windows and get the docs from the external HDD. If all of your applications are legit, this is doable. Weekly is enough. If there is some disaster (i.e. we had a flood in our building a few years ago), a weeks lost work is tolerable. Plus, most of my source code goes to a Subversion repository anyway. But, now I'm running Windows 8 with the previously mentioned "File History" feature set for 12-hour backups. We'll see how it goes. Good luck. I hope you never need to restore your drive!

When I first saw this comment, I thought it was ridiculous, but now I see a lot of beauty in the f actuality and irony of it. Here it is: // Note that there are 1024 milliseconds in a second

For my money, ANYTHING to speed up your work computer is worthwhile. The most expensive part of a PC is the operator! Also, each time a developer is interrupted (phone call, email, announcement, etc.), it takes about 20 minutes to get back up to speed. So, if a 30-second compilation does not interrupt you, but a 10-minute one does, you're talking about taking a 30-minute interruption, or probably about $50 charged. I'd say in a couple of days you'd pay for that SSD!

Before writing the coding standard, I would recommend reading "Code Complete" which gives some very specific arguments about naming conventions and other things that would be in the standard. The good news is that no matter what, just HAVING the standard, even if it's not perfect, will go a long way. For our company which is largely focused on embedded projects using C, we adopted one that was already well developed (Michael Barr's Netrino embedded standard), bought a few hard copies for our reference, and made a one or two page document that says that's what we're using and what changes to it we're implementing (very few tweaks). Taking this route (adopting an already written standard) saved us a TON of time (read money) and took out some of the "persona preference" discussions. If you're using C#, why not adopt Microsoft's standard and call it a day? (I realize this isn't exactly what you were asking about.)

In general, I try to make my variables "domain specific" and single purpose. So, if my function returns "milliamps" but can also return an "error code", I will usually have the function return an enumerated "error code" like

typedef enum {ERR_NONE, ERR_BAD_READING, ERR_BUSY} AdcErrCode;

and pass the returned "milliamps" value by reference. When I'm feeling really disciplined, I may even define the data type like "typedef uint16_t Milliamp". For your example, I would certainly return a separate error code like

typedef enum {STR_SRCH_FOUND, STR_SRCH_NOT_FOUND, STR_SRCH_BAD_STR} StrSearchErr;

or something and return the error code by reference. Typedefing your domain specific types add ZERO additional run time or memory overhead. Thoughtful, explicit typedefs also make your static code analyzers work a lot better. Note that these are examples from a C point-of-view. So, the point is not whether to use 0 or 1 as the first index, or what your error code should be, but to be extremely explicit in your data types (even in loosely typed languages) and variable names. An "index" in your search is not necessarily the same as a letter "count".

My favorite job was the first one where I actually got PAID, plus it was interesting and useful. For a professor at my college, I programmed a Macintosh (circa 1993) to talk to a piece of custom equipment which measured radiation in radon gas samples taken from aircraft. Pretty simple stuff by my standards now, but man was I proud when I got that $600 check! I bought myself a sweet new laser printer (which turned out to be a piece of junk, but that's another story...) The real lesson that I learned was this: I was "rejected" from getting a work-study job because somehow they thought my parents earned too much money (which was BS!). So, I went around asking professor if they needed any help and sure enough, this guy in the physics department needed some code written. Ask and ye shall receive!

It sounds like there is a big communication gap between the "coders" and the "managers." I think that maybe you guys should not take the blame, but you can take some responsibility to fix the situation. It is the responsibility of the employees to inform their managers about how things really get done. If agile works and it's an improvement over waterfall, try to educate them. Try to find out what the "real" goal of the managers is. Maybe documentation isn't really the goal, but the means to the goal. Maybe after finding out what they "really" want, you can get them there better. We are a small ISO-13485 company (kind of like ISO-9000 but for medical devices). That and our FDA requirements means a lot of documentation. But, the Engineers have learned what the FDA and ISO really requires and we constantly tweak our processes to become more efficient. In some ways, it's uncomfortable that we're never quite in the "flow" and no two projects run the same, but at least we are continuing to do the "overhead" work more efficiently. So, point it, talk to your managers and see if maybe there isn't some win-win way to work. Good luck.

"Calling" the managed functions isn't really a problem anymore. The real problem is passing in a reference to the unamanged event handler function into the managed event. Sorry to keep pushing on this, but does sound like you know what you're doing! Thanks again.

Peter, this is helpful, but at least half of the challenge is on the native (un-managed) side. I think now I have a syntactic problem with registering my native C function with the managed event. Any more tips? Thanks!

I have been struggling HARD to find a solution to this. In order to get some long-term platform compatibility (PC simulator, embedded target, etc.) I am implementing my main code in C, and a GUI emulator in C# as a DLL. I am able to make calls into the C# DLL from my native code by exposing the DLL functions as COM objects (I think...). Data are passed in and out of the library functions just fine. I would like to have callbacks made back to the native code when events are triggered in the C# code. You can imagine that when a button is clicked on my fancy C# GUI, my native code gets called. I cannot seem to get this callback mechanism working. Can anyone please give an example, syntax, etc. for assigning a native callback to a managed C# event (or something like that)? There are TONS of examples of using managed code to call un-managed DLLs, but very little going to the other way. Thanks in advance. -Stuart

I don't know if this is read or not, but this prank had me rolling: [^]

This may or may not help you, but I like to think of requirements as "what the customer needs", even when the customer is some other guy/department in the company. If it's "implementation", it's design. If they really do care about some aspect of the implementation, then that part could be a requirement as well. Think of requirements as describing the black box. For example, here might be some requirements: The software shall store the settings of the last 100 users. This should NOT be a requirement, but your implementation: The software shall use a MySQL database to store settings. Some other requirements: The system shall be able to operate for 24 hours continuously without needing the recharge the battery. The system shall be powered by a 9V battery. [<-- This could be a requirement because it fits into some other department's, the mechanical design, needs.] But these would be implementation: The software shall throttle the processor when possible to conserve power consumption. Making something a spec does not get you off the hook from testing, but it may affect the nature of the test. BTW, it IS worth spending time on figuring out how you want to handle this!

There have been many rookie errors pointed out by others, so I won't repeat them. There are a few general things that will help with your code: 1. Compile the code with the strictest warnings setting. The compiler will likely tell you about a lot of bugs, or potential bugs, lurking in the code. Do not use the code until there are no warnings. 2. Use a static code analyzer like Lint. It would have caught problems like your assign/compare bug. It will also offer many suggestions for cleaner code. See http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis[^] When you can compile code with no warnings, and get through Lint without much trouble, you are much less likely to have a real problem with your code. You'll be able to concentrate on the real meat of the code. Stuart

First thing, Object Oriented and Layered and not the same thing. Often they are both used, and often they are not. The science and art of Software Engineering is about managing complexity. Of course, if you have a very simple system, you will probably want a very simple software design - one or few layers, no object-oriented constructs. But, as your system grows with just the slightest complexity, be it hardware, timing, protocols, etc., you need some sort of layering or you'll have a huge mess of code. Layering and Object Oriented methods MANAGE COMPLEXITY. That's all they do. One example of layering not discussed in the thread is the ability to divide the work amongst a team by areas of expertise. Without layering, everyone would have to know everything. Does the USB protocol expert need to know about the application? Maybe not. Does the UI guy need to know about TCP/IP? Does the battery charger guy need to know about the application? Layering also makes testing much more thorough. You can test one layer independently from another. Of course, without layers, you could never integrate third party software libraries, stacks, etc. Object Oriented also thrives in this department. Take a nice library from someone and subclass their objects to your needs. So, I do believe that your software and the people you work with suck. No argument here. But, in my experience, thoughtful up-front design of layers of abstraction are the best, quickest, most efficient, and safest (I'm a medical device guy route. Stuart

First of all, I'm happy to read this forum and not see too many "religious" arguments for styling one way or another! There are good, objective reasons to use different styles. I always go back to McConnell's "Code Complete." Chapter 31 is all about layout and style. Basically, the layout style needs to address these. I'm quoting headings from the book: Accurately represent the logical structure of the code Consistently represent the logical structure of the code Improve readability Withstand modification I think the first two are obvious. The latter two are what require the thought. Personally, I'm a white-space-supremacist bracist (good pun, earlier poster!), and like:

// Check for matching data results
if(a == b)
{
// The data match.
doSomething();
}
else if (a == c)
{
// Something else matched
doSomethingElse();
}
else
{
// Something may have gone wrong.
doErrorCode();
}

The blocks are easily identifiable. It's almost impossible to screw up when you add code. It's also easy to comment; the comments naturally identify the blocks.

Most universities will have some sort of job placement program, and many will have full-fledged "co-op" programs, or internship placement people. As for your experience and under-class status, if you have some good programming skills, many employers will look beyond your lack of coursework. (I know I do.) Be sure to maximize your programming experience as much as possible in your resume. Personally, I would rather hire (or at least bring in for an interview) someone who puts programming as a hobby, had high-school experience, lists programming languages, etc., on their resume than someone who spent years flipping burgers or folding sweaters at the mall!

I'm not sure how things work in your university, but it may be possible to keep your Mechanical Engineering major and get a Computer Science "minor". It sounds like you really enjoy programming (which is great), but for some reason you did pick Mechanical Engineering as a career, probably because you also really enjoy making things. I am a strong believer that good programming skills are applicable to just about ANY career. So, if you can just trudge your way through ME, but pick up as many programming courses as you can, you may be quite qualified to do a wide variety of work. BTW, I don't care what major you take: you WILL have many courses that are boring (to you), tedious, difficult, and probably not applicable to real life. Suck it up. As for your job being repetitive, sure, there are meetings and documentation, but generally, as an Electrical/Computer/Software Engineer (and I know it's the same for my Mechanical counterparts where I've worked), no day of work is the same as another. Every day brings a new and exciting challenge. I might also suggest that you try to spend as much time as you can doing internships, "co-op" jobs, and other work outside of a university setting. This will will give a better taste of what things are like, plus it will help a lot to get a job when you graduate. Stuart