things keep in mind

[Ajay Negi]

what are the things a new developer should keep in mind while writing a program?
please reply.

[JamesCherrill]

Someone else is going to have to read and understand it.
Whatever the requirements are now, they will change.

[stultuske]

small modules are easier to debug compared to classes having methods with thousands of lines of code each.
Some sort of documentation is appreciated.
Follow decent naming conventions, whether the usual or those in your company, just don't use others in each class.
Choose variable names that are readable and understandable to others: not just the language, also describe what they're for

for instance:
int n = 17;
could be:
int numberOfRowsInTable = 17;

everybody knows immediately what it is used for, and knows they shouldn't use it for other purposes, risking changing the value.
if the developers in your company only speak/read french, change it to:

int numéroDeRowDansTable = 17;
don't use english by default because usually IT does, use a language you all understand.

Test your code. Don't wait until the code is either released in a TEST (or worse: production) environment to test it. Before you let testers perform functional tests, run unit tests to ensure you didn't introduce some regression bug.

Make sure you understand the analysis, and when in doubt, ask the analyst. make sure everything is 100% clear before starting to develop, otherwise, you risk hours of coding being reversed, and replaced by something else, which also takes hours of coding.

[~s.o.s~]

don't use english by default because usually IT does, use a language you all understand.

I don't really agree with this. Programming cuts across boundaries so always assume that the code you write will end up being maintained by some person on the other side of the globe who doesn't speak the same language as you. English has clearly emerged victorious as a de-facto language for writing programs and communicating with fellow developers (look at any major open-source/closed-source project).

Also, this is a problem because once you get into the habit of naming things in a localized language, you'll find it hard to work at any of the well-known (or maybe Fortune 500 as some call it) companies. After all these years of working as a programmer, I have never seen a developer get away from code reviews after using localized names. :)

Regarding naming, don't clutter your class with single alphabet names but at the same time don't go overboard with naming variables. As long as you keep your functions/methods tightly defined, names don't pose much of a problem (as long someone is half-decent at naming them).

Give extra thought when naming class variables; a mess-up with local variables is still acceptable (because they can be fixed easily) but when you start leaking bad names throughout your code base, stuff goes bad.

I feel the most important thing with programming after all these years is "balance". Should this method be 200 lines long or maybe I can make it "extra" modular and split it into 10 line methods (thereby resulting in an explosing of method names)? Should I use a factory of factories here or just use a plain class hierarchy? Should I start off with a depedency injection framework and 10 fancy libraries as opposed to a small core and then fan out? Exercise your judgement. Maintain a balance; going overboard either way hurts.

Learn to priortize your time. Make a list of things to be done, order them based on importance (discuss with manager/stakeholders).

Keep revisting your code. Between a bad code which is frequently revisited by developers and refactored and a OKish quality code whihc never gets revisted, I would be more comfortable working on the bad quality code. Your software becomes a mess when you stop evolving your existing code based on the changes you make for new features.

[newcoder310]

Since, this is a Java sub-forum, I assume that you have asked this w.r.t java. From my personal point of view below are a few things that are really necessary for writing a java program.
1. Understand the requirement clearly. Even for the smallest of the program.
2. Design your program. Ensure that its reusable. Ensure that you follow good OOP principles mainly Coupling and Cohesion. If possible, see if you can use a Design pattern.
3. While writing a program, the main thing is to try to keep it simple. OOP ensures that programs are written in a simple way. If you adhere to OOP principles, your program will be simple. Follow whatever @stultuske mentioned.
If you are programming in groups, ensure that you take one class/package/feature. Adhere to standard conventions throught.

There is a saying

program to interface not implementation

[stultuske]

~s.o.s~

don't use english by default because usually IT does, use a language you all understand.

I don't really agree with this. Programming cuts across boundaries so always assume that the code you write will end up being maintained by some person on the other side of the globe who doesn't speak the same language as you. English has clearly emerged victorious as a de-facto language for writing programs and communicating with fellow developers (look at any major open-source/closed-source project).

Yes and no. My point was not that using english was a bad option. My point was, if nobody of your team speaks english (and trust me, teams like that do exist) using english, even though better for potential future developers on the project or outsourced (which are things that will not always happen), might not be the best option.

of course it is important if the future maintainers (if any) will be able to understand the project quickly, but that should not mean it has to be more difficult for those working on it now.

[JamesCherrill]

It's a cliche, but software lasts long beyond its initial expected life. Management have some rose-tinted idea that they can replace it in 2,5,8 years or whatever, but once it's in place it's always cheaper to do a "small" fix or upgrade than a complete re-write.
So, IMHO, the people you are writing for when you write code are the poor minions who will be creating incremental update number 23471 in n years time.
Hence my first off-the-cuff response to this thread:

Someone else is going to have to read and understand it.
Whatever the requirements are now, they will change.

[newcoder310]

but once it's in place it's always cheaper to do a "small" fix or upgrade than a complete re-write.

From what I have seen, the trend in the industry now-a-days is that there are no SMEs on a product. In the sense that at max people stay for 10 years(This is wrt to 75-80 percent of the industry. Not everyone) in a company or with a product and after that cycle, either the code is obsolete or none have knowledge on the product. Along with this, technology is constantly evolving. So most companies are preferring to upgrade.
Example: Classis case where almost all the products that were using applets are being replaced or major rework is being done to replace them as the lastest browsers announced that they won't be supporting applets any more.

[Ajay Negi]

Thanks a lot.
As i'm a student and i have lot of questions.
what are variables and why we use them?

[newcoder310]

There are a bunch of tutorials or books. Please go through them. Even if you just google something like variables java, you'll get a bunch of search results. Please post if you have a specific question.

https://docs.oracle.com/javase/tutorial/java/nutsandbolts/variables.html

[stultuske]

JamesCherrill: even while I agree that in most of the times that is true, it is not always.

For the last x years, here, a program had to be changed? they had just changed frameworks, background, and for some reason, decided it best to re-write the entire thing.

As for "we'll outsource it", our applications are about very sensitive and legally protected matarial => outsourcing is a no-go.

"Someone else is going to have to read and understand it"

true. So, in a country where everybody speaks and understands (just an example) dutch, and only half of the people understands english, what will they understand best?

I'm not trying to advocate the "ignore english" point, I'm just saying that even though writing it in a way that those who'll have to maintain it later on is good, writing it in a way that those who are currently developing the system can understand it, is better.

Those maintaining it will have documentation at hand, so they should be able to easily go through it anyway.

[jwenting]

documentwhat?

Management have some rose-tinted idea that they can replace it in 2,5,8 years or whatever, but once it's in place it's always cheaper to do a "small" fix or upgrade than a complete re-write.

or worse. I've had to work many times on systems that would have been far cheaper to replace 10-20-30 years after being written but were maintained because for political reasons it was impossible to get budget for replacement but getting a higher budget for maintenance was no problem.
Worst case of that was literally a 30 year old system running on hardware that was no longer in production, including spare parts, due to the manufacturer having years ago gone out of business. Replacing it would have cost a hefty 10 million or so Euro over a 3-4 year period. Maintaining it cost 5 million a year, plus several hundred thousand more just to train new staff to do the work.
The department had literally bought up ALL hardware for the system it could find when the manufacturer went out of business, and had people near fulltime browsing eBay and similar places looking for more, just so they could stave off the inevitable day they'd run out of spare parts.
New staff had to go through a 3-4 month training program just to become proficient on maintaining the hardware and software, for which they had several people employed near full time just to provide that training.
The system was (and it's still running 5 years later) mission critical, failures leading to massive economic damage and potentially serious loss of life (sorry, still under an NDA so can't disclose what the system is exactly).
And still they found it impossible to get proposals to replace the dinosaur approved and budget appointed.

[Ajay Negi]

what are variables in java and why we use them?

[stultuske]

Ajay, for a new (unrelated) question, please start a new Thread.

But for this question, I would recommend:

https://docs.oracle.com/javase/tutorial/java/nutsandbolts/variables.html

[Ajay Negi]

how anonymous object is used in java?

[stultuske]

Ajay: again, if you have other, unrelated questions, please start a new Thread.
Or, put your question in google, and click search. These things are neatly explained in the official Java tutorials:
https://docs.oracle.com/javase/tutorial/