Programming Forums - School days drama

Programming Forums (http://www.programmingforums.org/forumindex.php)

- C# (http://www.programmingforums.org/forum16.html)

- - School days drama (http://www.programmingforums.org/showthread.php?t=12351)

School days drama

Im doing an assignment in my C# class. The idea is to make a program to takes a month ( ie 05) day ( 1-31) century ( ie 20) year (ie 07) .

It takes the date and shows what day of the week that is.

Im doing it section by section, and im stuck on the first section.

Here's how my working code is looking so far:

using System;





public class ddate

{

        

        

        public static void Main(string[] args)

        {

                /* This program will accept a date from the user

                         * and display the day of the week.

                         */

                        

                //a user is inputing numbers and I can use int 

                // to verify that.  



                string month , day , century, year ; //strings will convert to int 



                Console.WriteLine("I am going to ask you a series of questions. Press enter to continue");

                Console.ReadLine();

                Console.WriteLine("This is newb code. Enter values exactly as directed. Press enter to continue");

                Console.ReadLine();      

                        

                    /*Basically the program starts here.  I just need some solid

                         ways to check if the user does it right. Suggestions? */





                Console.WriteLine("Enter a two digit month. ie 08 for August");

                month = Console.ReadLine();

                Convert.ToInt32(month); 



                Console.WriteLine("Enter a day. 1 - 31 PLEASE!");

                day = Console.ReadLine(); 

                Convert.ToInt32(day);



                Console.WriteLine("Enter the century. ie the '18' in 1870. TWO DIGITS");

                century = Console.ReadLine();

                Convert.ToInt32(century);



                Console.WriteLine("Finally enter the two digit year. ie the '70' in 1870. TWO DIGITS") ;

                year = Console.ReadLine();

                Convert.ToInt32(year);



                









                   

                

}



        }

You don't say what you're stuck about. You can easily think of ways to validate the user's input. Certain months have 30 days, others have 31, and ol' February needs to know the year mod 4, mod 100, and mod 400 to reasonably determine the leap year situation.

As far as determining the day of the week, look up Zeller's congruence. Of course, if you have libraries, and you do, the time functions will do that for you. It's helpful if you're ever programming on a bare-bones system, though.

hmmm.... tell me more!

The easiest way to accomplish something like this is to use DateTime from the System namespace. First you build the string from user input, then try to create a valid DateTime instance from it using DateTime.Parse(). This will return a valid object if successful, and otherwise, it will throw an exception. If you're not comfortable using exceptions, or wish to simplify the code, you can use DateTime.TryParse() instead. This will accept an out DateTime parameter (semantically, this is just a ref parameter that doesn't need to be initialized prior to the call), and it will return a bool to indicate whether it succeeded. If it returns true, that means that the DateTime parameter has been filled in with valid information; otherwise, the string you provided could not be converted to DateTime.

There are also a whole host of methods and properties of DateTime that you can use to display or process the information however you like.

Ok coming good. I edited my switch statement a bit. I want to fall through the switch statemement like
do case 1
do case 2..

etc.
Up till 4. How do I go about doing that? I tried goto and it wont work for me.

switch(time)

                {

                                           

                        case 1: System.Console.WriteLine(" Enter the century. ie 20 or 19.");

                                C = System.Console.ReadLine();

                                Convert.ToInt32(C);

                        goto case 2;

                                

                                       

                                        case 2: System.Console.WriteLine("Enter year in YY format. ie 96") ;

                                        Y = System.Console.ReadLine();

                                        Convert.ToInt32(Y);

                                        goto case 3;

                                        

                                   

                                        case 3: System.Console.WriteLine("Enter month in MM format. ie 03");

                                        M = System.Console.ReadLine();

                                        Convert.ToInt32(M);

                                        goto case 4;



                                        case 4: System.Console.WriteLine("Enter the two digit day of the month. ie 13");

                                        D = System.Console.ReadLine();

                                        Convert.ToInt32(D);

                                        break;

                                }

The default behaviour of a switch statement is to fall through each case to the next one. That's why you usually have to put a "break" at the end of each case block. Remove each "goto" line and it should work as you wish.

As a rule of thumb, "goto" should never be used. I suspect there are extremely rare cases where it might be useful, but I have yet to discover any of these cases. Steer clear of goto.

Quote:

Originally Posted by Arevos (Post 122599)

One problem with this is C# doesn't like these fall-throughs. It allows them are when there is no code between case labels. That is,

case 0:

case 1:

  <code here>

  break;

is okay, but

case 0:

  <code here>

case 1:

  <code here>

  break;

is not. I also believe that if the case block contains an unconditional return (or more accurately, all code branches inside that case block contain a return), the compiler will accept it (since the return will prevent fall-through). Otherwise, the compiler bitches; I believe the rationale is that it's a common source of coding errors, and (to some) bad style.

Quote:

Originally Posted by Arevos

As a rule of thumb, "goto" should never be used. I suspect there are extremely rare cases where it might be useful, but I have yet to discover any of these cases. Steer clear of goto.

I wholeheartedly agree.

@OP: You might want to make it clear whether your numbers for month and day are zero-based or one-based. For example, is January zero, or one? You could look into using an enum for the months (and days of the week).

Also, your reason for using a switch block escapes me. Since the pieces of code progress in sequential order, and always fall through, what is the point? Just stick 'em in series, and ditch the switch. If your purpose is because the user doesn't always need to enter the higher-order values (ie, if they skip the year, it will use the current one, or some other defined default), then you could use a switch inside a loop, and then increment or decrement the switch expression in the loop.

Offtopic on goto's:
If you ever write a lot of error checking C code, goto will become your friend. Projects like python and opencv use it a lot internally for error handling. Lets say you have a set of operations that has many steps and complex error recovery code. Rather than having a confusing nesting of conditionals you can just jump to the error cleanup whenever you hit an error.

ASM is made of gotos. That does not make it your friend. It is an enemy, a devil that tends to lead you into iniquity. Internal usage is of no consequence, as internal usage is the backbone of actual emitted code for the processor. At least 90% of the time, if not 99%, it is, in a higher level language, indicative of poor understanding of the usage of the language. Sure there are exceptions; there almost always are. That's why I maintain that it is not intrinsically evil.