Zeros...

[halt4814]

How to I get rid of the zero before decimal data points? For example, if I get data that is 0.789 or -0.342, how do I make it so it reads .789 or -.342?

[BioPhysEngr]

public static string stripZero(string num)
{
    if( num.StartsWith("0.") )
        return num.Substring(1);
    if( num.StartsWith("-0.") )
        return num.Substring(2); //EDIT: A bug in this line was identified by Peter B; see below
    return num;
}

[halt4814]

Works! Thanks

[Peter_B]

Works! Thanks

It won't be working for negative numbers - as it is stripping off the '-0' at the beginning. Needs a slight change to fix this:

public static string stripZero(string num)
{
    if( num.StartsWith("0.") )
        return num.Substring(1);
    if( num.StartsWith("-0.") )
        return "-" + num.Substring(2);
    return num;
}

[Jim_Auricman]

Here is another solution:

        string stripZero(string OriginalNumStr)
        {
            string ModNumStr = OriginalNumStr;
            int DotIndex = OriginalNumStr.IndexOf('.');

            if (DotIndex > 0)
            {
                if (OriginalNumStr.StartsWith("0.") || OriginalNumStr.StartsWith("+0."))
                {
                    // For positive numbers--
                    ModNumStr = OriginalNumStr.Substring(DotIndex);
                }
                else
                    if (OriginalNumStr.StartsWith("-0."))
                    {
                        // For negative numbers--
                        ModNumStr = "-" + OriginalNumStr.Substring(DotIndex);
                    }
            }
            return ModNumStr;
        }

[Peter_B]

Here is another solution:

        string stripZero(string OriginalNumStr)
        {
            string ModNumStr = OriginalNumStr;
            int DotIndex = OriginalNumStr.IndexOf('.');

            if (DotIndex > 0)
            {
                if (OriginalNumStr.StartsWith("0.") || OriginalNumStr.StartsWith("+0."))
                {
                    // For positive numbers--
                    ModNumStr = OriginalNumStr.Substring(DotIndex);
                }
                else
                    if (OriginalNumStr.StartsWith("-0."))
                    {
                        // For negative numbers--
                        ModNumStr = "-" + OriginalNumStr.Substring(DotIndex);
                    }
            }
            return ModNumStr;
        }

Yes, if you really want to avoid multiple returns then this is the way to do it. But it isn't as easy to read as the solution given by BioPhysEngr (with my correction).

[Jim_Auricman]

"Yes, if you really want to avoid multiple returns then this is the way to do it. But it isn't as easy to read as the solution given by BioPhysEngr (with my correction). "

If you follow the coding standard of "Single entry, single return" it is easier to debug. If you set a breakpoint at the return statement at the end of the function, you can be sure it will be hit. If there are multiple returns embedded throughout the function, you would have to set breakpoints at every return statement, and it is possible that some may be overlooked. There is a reason the software experts put the "Single entry, single return" rule into the standard. They obviously thought it was a cleaner way to write a function. I agree with their thinking, but I realize that some software people (very intelligent & knowledgeable people) today do not always agree; I don't lose any sleep over it since I don't have to maintain their code.

[BioPhysEngr]

@Peter: Thanks for the good catch.

@Jim: I think we've argued the multiple returns issue in its fullness. No need to have it again here.

[Peter_B]

@Jim: May I start by saying that I agree that multiple returns, in general, can be a bad thing as they certainly can make code harder to understand and debug. Having said that, a couple of points:

"Yes, if you really want to avoid multiple returns then this is the way to do it. But it isn't as easy to read as the solution given by BioPhysEngr (with my correction). "

If you follow the coding standard of "Single entry, single return" it is easier to debug. If you set a breakpoint at the return statement at the end of the function, you can be sure it will be hit. If there are multiple returns embedded throughout the function, you would have to set breakpoints at every return statement, and it is possible that some may be overlooked.

In fact, you can just put a breakpoint at the closing brace:

int anyFunction()
{
    ...
    // lots of lovely code
    ...
} <-- put breakpoint here

This will catch all returns. And while coding to make debugging easier is obviously a great thing to do, in this particular case the original solution is only five lines of code, and is unlikely to need checking through a debugger. Admittedly it had a bug, but that would have been spotted immediately when a negative value test case was created.

There is a reason the software experts put the "Single entry, single return" rule into the standard.

I don't know what 'standard' you are referring to here, but 'Single entry, single return' (or exit) is a tenet of structured programming which precedes C++, and was designed to apply to languages which have explicit resource management (such as C). After all, since when has there been any thing other than 'single entry' in C++ functions?

But we are clearly not going to fully agree on this matter, so we'll have to agree to disagree

[Jim_Auricman]

After all, since when has there been any thing other than 'single entry' in C++ functions?

Believe it or not, I have seen code that used multiple entry into functions. Back in the days when code space and execution time was very critical, some functions were written with several different entry labels so one could jump to the point where one wanted to begin rather than writing several different functions that were somewhat similar in function. Needless to say, this could get very confusing, so it was decided to discourage the practice. I believe modern languages do not even permit you to do this anyway, but they do allow you to have multiple returns. I have debugged functions that were several pages long with 5 or 6 different returns, and this can be a nightmare to debug. Often the guy who wrote it is long gone, so you must figure it out on your own. A former supervisor once said, "OK, the function works, so the job is half done. The other half of the job is to make it understandable and maintainable." I think his idea was correct. Much of the time spent on software is maintaining previously written code. Requirements often change, so one often has to go back and modify the code to meet the new requirements. Following structured coding standards make code maintenance so much more efficient and less nightmarish. But often seeing code that is written by brilliant people today reveals that coding standards are not in vogue.
I do not wish to make this a personal issue, that's why I just entitled the last function as an alternate solution.

[BigEd781]

"Yes, if you really want to avoid multiple returns then this is the way to do it. But it isn't as easy to read as the solution given by BioPhysEngr (with my correction). "

If you follow the coding standard of "Single entry, single return" it is easier to debug.

I disagree. Single return is a good standard for languages in which you manually manage memory. This is not the case in C# and early returns make code more readable in many situations IMO.

[BioPhysEngr]

Single return is a good standard for languages in which you manually manage memory. This is not the case in C# and early returns make code more readable in many situations IMO.

Now that you say it like that, I think that is probably the most reasonable position. Thanks for expressing it so clearly.

[Peter_B]

Just noticed that I said C++ when I meant to say C# in this bit:

After all, since when has there been any thing other than 'single entry' in C++ functions?

In C++ of course, as Jim_Auricman said, you can have multiple entry points to a function (or at least, you used to be able to - I don't know if you still can with modern compilers).