Tag Info

Hot answers tagged

55

Doesn't it mean it's rare to have things right right away? Exceedingly rare. In fact, if things run 'right' the first time, I normally assume that something is drastically wrong. Does it mean that the people demanding correctness right off the bat are unreasonable? Completely and utterly. And now, what is the way to avoid making mistakes now? ...


28

For flexibility -- this has to do with what happens when you change the class later. If foo.x is a publicly accessible member (even a final one), and you decide that you no longer need that member, code which accessed that method is now broken. If you have only provided a getter, then you can always provide a compatibility version of that getter which ...


18

Personally I'd be most concerned about the "forgotten line" and the "missed method call". Everyone makes some mistakes, and like everybody says the most efficient way to find things like typos is with the compiler, not with repeated manual proofreading of all your code before you present the first version to the compiler. Some IDEs help with this too. ...


7

The first problem that comes up in such a design is "what if something isn't final anymore?" You've decided that 'no, you really do need to change that field sometimes' and so when you remove the final, you're left with a public int field; sticking out there for anyone to fiddle with. The next problem is, you've got to keep using it. Its part of the ...


7

There are two things of note here: you seem to know quite a bit about good practices and the project is meant to disappear "soon" (though not right after you leave). As Telastyn mentions, make the most out of this experience to learn what works and what doesn't and how to apply best practices in a real-world environment. Think about yourself first. That ...


6

The point of an internship is to learn. I would refactor the code to be better and ignore the assumed limitations of people you don't know. For all you know, the company will move that project to an internal team rather than interns soon.


6

The people criticizing me say I need to be able to make code without bugs. Those people are wrong. There is nothing bad at making bugs on the first try. In current days of quick, incremental compilation and intelligent IDEs, that mark errors without compiling, first-time methods are not that big problem. It is much more profitable to put your energy and ...


6

First: It is reasonable to use Functions instead of fields, because the syntax is different! If you have Code which ist int x = point.x and you decide to change the internal representation of Point to a lazy model which calculates x only when needed, you would have to refactor all legacy code, since a public field access and a method call are fundamentally ...


5

I'd like to add something people haven't mentioned: You can override getters and setters and you can specify them in your interfaces. You cannot do this with fields.


4

The majority of my bugs are most often not algorithmic (such as mistaking one var for another, a forgotten line, a missed method call). I used to make this kind of mistakes, a long while ago. This happens due to rushed code, spagetti code and too tight coupling (resulting in having to keep track of too many things at the same time, while writing an ...


3

Doesn't it mean it's rare to have things right right away? It is usually normal to not get everything right right away. Case in point, if you are working with a client, sometimes not even they know what they want, so potentially they could come back to you a couple of times to fix parts of your code. Also, people with different job descriptions tend to ...


2

I take a slightly different perspective on the issues you raised than most other commentators. I apologize for a long response, but I wanted to draw as many examples as well as issues because these issues can make a significant difference in one's careers. I have had to personally go through hard times in my career, and thus I wanted to share what I learnt. ...


2

The notion that professionals never make errors is ludicrous. Professionals do two things that amateurs do not. The first is that they shorten their feedback loops. Have you ever made a typo? Would you finish typing the document, discover it, and then decide to throw out a document if you did? It's crazy right? This was a real problem for ...


2

The answer is that getters and setters give the library writers the flexibility to change the internal workings of their library without requiring users of that library to recompile every time a change is made. This area is called Binary or Behavioural Compatibility, and is one of the basics of Software Engineering and came about because exposing the ...


2

It's not always recommended, read for example the Android guidelines: Avoid internal getters/setters Virtual method calls are expensive, much more so than instance field lookups. It's reasonable to follow common object-oriented programming practices and have getters and setters in the public interface, but within a class you should always access fields ...


1

Sometimes something you get from an object is stored internally as a field, and sometimes it isn't. The example I use with my students is a Date class. It would be madness to represent a date internally as a separate day, month and Year; you just use the number of days passed since some reference day. This ensures consistency, and makes it easy to compare ...


1

I think it's mostly because of legacy reasons. Some of Java's older apis are not immutable (the Date class is a mutable object, there is probably an alternative in java 8 now). Thus an argument for using getters is to potentially return immutable instances of these older objects. This is in contrast with functional programming where everything is ...


1

Your question has two major concerns: should I write good code, even if the next person may not understand it? and, how to I make sure that my efforts are not wasted if a less experienced person takes over after me? As to the first, you should always write the best code you can. We know that code written with design patterns and principles is flexible, ...


1

I couldn't disagree more with the people who say "code should work right the first time". It's nonsense. You can write code very carefully and very slowly and have code that works right the first time after four hours. Or you can write code very quickly that compiles and runs after an hour, with all the bugs fixed after two hours. So what is better? My ...


1

It's possible to create perfect code the first time. It just takes some years of practising and writing large amounts of code. How it works is that you'd verify the code correctness while writing it. Instead of randomly writing code and hoping it would work, you write the code and immediately verify the correctness. Any errors you find need to be fixed ...


1

You mentioned nothing about the scale of the projects you have to work on. Eitherway writing large amounts of flawless code is impossible, trying to is a good thing but it should not be compulsive because that will slow you down. When you are confronted with a new problem, you must grasp it intuitively and start writing, gradually you will figure out what ...


1

In this business, be really careful about taking others' criticisms too much to heart -- be attentive, of course, and always try to improve yourself, but don't just accept others' characterizations of you. There are lots of people who play stupid power games in order to favor their position in the organization, or else favor their personal technical ...


1

A popular method nowadays is Test Driven Development. You start by writing the test case, which obviously fails since the actual code is still missing. This is thus a perfectly normal situation while you're developing. But to finish your task, the test cases you added must pass. As a result, you go from "code still in development" straight to "all tests ...


1

Remember that training sets are meant to encourage learning. I see that message as just a morale booster to encourage you to continue. For simpler programs, it is often a matter of focus to code without any bugs. For complex tasks with many interacting classes, there is always the possibility of a bug even with expert programmers. Proper coding practices ...


1

This is an example of Symbian S60 code review checklist that was used as mandatory input into both peer review and formal inspection processes applied at Tieto, Telecom division in 2008 Outputs of the code reviews could influence the contents (and priorities of the points) on this checklist. Beside this simple list of points we also had more detailed ...


1

I would avoid creating constants (magic values) to convert a value from one unit to other. In case of converting I prefer a speaking method name. In this example this would be e.g. DayToSeconds(num_days) internal the method don't need magic values because, the meaning of "24" and "60" is clear. In this case I'd never use seconds / minutes / hours. I would ...



Only top voted, non community-wiki answers of a minimum length are eligible