[AthenaDX]

string strSaveForWeb = Form1.axError.MyReadProf("MDIN", "SaveForWeb", Form1.strInstPath);
                if (strSaveForWeb == "False")
                {
                }
                else
                {
                    AddSourceDB();
                }

There's a more efficient way to do this, my brain is just kinda dead today due to long weekend.

Not sure if a switch case would be more efficient or if I should switch to boolean as there's only two cases really.

@___@ WHY ARE YOU DEAD BRAIN?!

In other news, when is if then more efficent than switch case and visa versa? I want to code as efficiently as possible.

[tlhIn`toq]

Don't get eaten up with worrying about one over the other in terms of efficiency. These aren't 286 computers. Efficiency is more about entire long running loops than the speed of a single if.

If you're running the comparison a million times there might be a difference. Try it. Do a million if in a loop, and a million switch in a comparable loop and time them.

For your situtation of only true/false then yeah, use a bool.

if(bSaveForWeb) AddSourceDB();

[AthenaDX]

Thanks, I'm still new at this job and fresh out of college so I freak out when I need to show people my code still. After talking to a buddy, he said he didn't feel comfortable with it till 6 months later. I'm only at the one month mark. /end ramble.

Anyways thanks. I'll use boolean then.

[Momerath]

A quote for you: "The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet." — Michael A. Jackson

[jon.kiparsky]

I'm pretty thoroughly ignorant when it comes to C#, but in most languages I'd prefer to see

string strSaveForWeb = Form1.axError.MyReadProf("MDIN", "SaveForWeb", Form1.strInstPath);
                if (strSaveForWeb)
                {
                    AddSourceDB();
                }

I would assume this does the right thing in C#, right?

As for the efficiency question, yes, it's usually better to get it working and then worry about efficiency later. However, from a style perspective, my inclination is to avoid decision branching if possible, and push it as far down in the code as possible. For example, never use a switch to set values, use a map for that. And in this case, I'd wonder if I could arrange AddSourceDB() such that taking a string that evaluates to false would cause it to return without doing anything. Then your code would look like this:

string strSaveForWeb = Form1.axError.MyReadProf("MDIN", "SaveForWeb", Form1.strInstPath);
            AddSourceDB(strSaveForWeb);

or even

 AddSourceDB(Form1.axError.MyReadProf("MDIN", "SaveForWeb", Form1.strInstPath));

which might be more readable if I knew what MyReadProf was and what it did.

However, it should do exactly the same thing as your original code in any case.

[AthenaDX]

bool bSaveForWeb = Form1.axError.MyReadProf("MDIN", "SaveForWeb", Form1.strInstPath).ToLower() == "true";
if (!bSaveForWeb) AddSourceDB();

Ended up with that by the end of it. Makes me happy to snip it on down to a couple of lines. Boolean was definently the way to go.

Thanks for all the information guys!

[Skydiver]

As a quick aside, the .NET Framework style guide discourages the use of Hungarian notation for variable names. http://msdn.microsof...y/ms229045.aspx

[tlhIn`toq]

Skydiver, on 26 November 2012 - 03:56 PM, said:

As a quick aside, the .NET Framework style guide discourages the use of Hungarian notation for variable names. http://msdn.microsof...y/ms229045.aspx

Yes it does. But I don't. Style is part of the artistry of coding. Some people like this

if (someBool) someString = "Yogi";
else someString = "Bear";

I prefer

someString = someBool ? "Yogi" : "Bear";

Its a style choice.



I have my own reasons for keeping this 'old school' convention:

From the Properties tutorial:

tlhIn`toq, on 10 November 2012 - 06:08 PM, said:

---

Footnotes

¹Naming convention:
Some people and some programs such as StyleCop or ReSharper will suggest renaming _Age to _age because it is a private field. That's just a very common style convention. I don't follow it because of something I've learned over time: Find and Replace is best used when case sensitive. I like naming everything that has to do with the same purpose using the exact same term, so if I have to Find/Replace everything related gets changed together.

• Button btn_Age
  
• Lable lbl_Age
  
• int Age
  
• int _Age

All of these will rename together and the same if I Find/Replace "Age" with "CustomerAge"

• Button btn_CustomerAge
  
• Lable lbl_CustomerAge
  
• int CustomerAge
  
• int _CustomerAge

This post has been edited by tlhIn`toq: 26 November 2012 - 03:29 PM

[jon.kiparsky]

Count me as an anti-hungarian. To me it's noisy, and I want to get the noise out of my code. And also, obviously, it's un-American, and I use American naming conventions.

[Skydiver]

Hungarian notation:

typeSomething:

int nShoeSize;
int [] rgnAge;
Label lblFocus;
MyDomainClass mydomainclassPrimeInstance;
string _szName; // or m_szName for a member variable

where type is either the type name fully spelled out, or a some set of prefixes by convention.

To me, this is not Hungarian notation:

somethingType:

int shoeSizeInt;
int [] ageIntArray;
Label focusLabel;
MyDomainClass primeInstanceMyDomainClass;
string nameString; // for a member variable

What's funny is that for .NET and JScript code, I eschew Hungarian notation except for the following cases:
- '_' to denote member variables;
- 's_' to denote static member variables (which I typically only use for debugging); and
- 'txt', 'rtb', etc, for controls.

Whereas for C/C++ code, I religiously apply Hungarian notation.

I guess it depends on my anticipated debugging support. For .NET code, I can usually rely on the debugger to give me the information I need, while writing C/C++ code where I maybe forced to use only windbg with barely enough symbol or line information.

[AthenaDX]

I just name variables by the guidelines that my company has set. Hungarian Notation happens to be how they want it structured along with _ in front denoting a global variable.

[jon.kiparsky]

AthenaDX, on 27 November 2012 - 10:04 AM, said:

I just name variables by the guidelines that my company has set.

Perfectly reasonable. As long as everyone's doing it the same way, you can get used to it. What's horrible is a code base with some hungarian, some javaStyleCamelCase, some old_school_underscore, and a lbogi (that's "a little bit of gratuitous initialism" - but you understood it, right?). That's when it's time for a good rampage.

[ihatesegfault]

tlhIn`toq, on 26 November 2012 - 03:27 PM, said:

I have my own reasons for keeping this 'old school' convention:

From the Properties tutorial:

tlhIn`toq, on 10 November 2012 - 06:08 PM, said:

---

Footnotes

¹Naming convention:
Some people and some programs such as StyleCop or ReSharper will suggest renaming _Age to _age because it is a private field. That's just a very common style convention. I don't follow it because of something I've learned over time: Find and Replace is best used when case sensitive. I like naming everything that has to do with the same purpose using the exact same term, so if I have to Find/Replace everything related gets changed together.

• Button btn_Age
  
• Lable lbl_Age
  
• int Age
  
• int _Age

All of these will rename together and the same if I Find/Replace "Age" with "CustomerAge"

• Button btn_CustomerAge
  
• Lable lbl_CustomerAge
  
• int CustomerAge
  
• int _CustomerAge

If you use a nice IDE (like NetBeans) then you can use Refactor, instead of Find/Replace and it will only change that variable's name and do it for the whole project too.

[jon.kiparsky]

So what I'm wondering is, how often do you find yourself needing to find/replace a variable name? I don't think I've ever done this, myself.

[Skydiver]

With Hungarian notation, I've ended up changing variable names when I changed from:

int nCount;
AnotherBigClass anotherbigclassData;
DWORD dwDataSize;

to

ulong ulCount;           // change data type is Windows Hungarian
AnotherBigClass abcData; // new agreed upon prefix
DWORD cbSize;            // change from Windows Hungarian to Office Hungarian