Its one of the bad thing when managing the project. There are many programming languages where you don't even need to declare the variables and at the first use it gets declared and such things are the worst part of it when you tend to make spelling errors and new variables are automatically declared.

Its not all about disadvantages but definitely some advantages as well. I would vote for it as an advantage because I don't need to be a very correct in syntax to get off with the language and when I am confident I can definitely opt for forced varaiable declaration and array sizes.

But the other way to look at it is you are learning the wrong way from starting and then when you get into real projects you tend to apply the wrong things.

Click to expand...

We start applying something.

Also about the array being expandable when you insert more elements you tend to focus on your logic rather than concentrating on how to go about perfecting the language you tend to perfect your own business logic.

Then you are leaving upto the compiler to go about optimizing your business logic. If you are not sure how many elements your business logic can have then its better to be using more flexible option then arrays.

The harm is you don't have the option of limited input then. But if arrays is something which can take n input and then when needed more then it can be relocated or if you are not sure then you can use something like List where we have unlimited input serving both the purpose.

Why is nobody considering the point of increased compilation and execution time in case of 'enabled array bounds cheking ? ' ..... can't we just say that it's good for debugging and fixing errors in the development phase and once the code goes into production the array bounds checking can be turned off ??

It should be the other way round. Infact when in development mode it hardly matters the extra bit of time but when in the production environment it matters and so we should have that option turned on (Bounds checking on) in production.

Again the disadvantage is if you change the option from development to production you can have surprises when doing the deployment and so its never a good option to have different setup for development and deployment.

I will give you one example as to the chat software we worked on and in worked perfectly fine in the development environment as well as the testing environment of our network but when deployed it just crashed when we double clicked on the exe and everything that we did like primary testing was questioned but after a day or two of debugging in the development environment ( Because we could not debug in the client environment ) we realized that there network had a firewall setup and we used the chatting on a port which is blocked by the firewall on the client network. Remember to get as close as possible to the production environment so that you don't have to face such problems. The solution to the problem was finally to change the port at which chat application worked.