No, I didn’t sit Udacity.. Please go back to that code, and edit it by indenting it correctly; it is very difficult to read.
If you show a potential employer code so badly indented, he will throw your application in the bin and never even see things like labelled continue and == on reference types.
No, but from what I've seen now (just a quick look) I am not impressed.
i am more of udacity-kind-of guy, rather than reading about concepts, i learn better by doing them.
Not such a promising statement.
if i took OCJP, whether i could be employed as java programmer ?
You'll work as a developer only if you are competent enough and you can actually prove that. The code above shouts that you really need to work a lot and hard (like we all did when we first started) before you start thinking about OCJP and getting a job.
The quieter you are, the more you are able to hear.
karthik ka wrote:SO Except for "continue" and "classnames" , is it indented?
Basically, no. Here is an excerpt from your code.
Here is the same code with some indentation.
Notice how much more readable it is?
This may seems like a bunch of grammer police being anal annoying at the moment, but think of it like this. First, if people can't easily read your code, they will come off as badly judging your code. And in the case of a job interview, you don't want that. Second, if people can't easily read your code, it can be argued that you can't easily read your own code. And it may be concluded (correctly or not) that this is a case of "throw away code" and you don't care about it. Your need to come off as a developer who is proud of what is produced (especially during the interview).
So, your question is, "Based on this sample of my code, could I get a job as a Java Programmer?"
That's a pretty fuzzy question, as one simple code sample is not enough information on which to make a hiring decision, unless it's so horrible that I can decide that there's no way I'd hire that person.
And aside from that, even to assess the quality of that code sample itself, there's more context we'd need. For instance, what question were you answering or what problem were you solving when you wrote it? What kind of time constraint did you have? What resources did you have available to you? What other constraints or freedoms where there? (For example, was it required to compile and run, or was it just meant to show a general concept?)
Aside from that, simply looking at the code in a vacuum, I have the following comments/questions:
1. Why is Sub declared package-private?
2. "Sub" seems like a poor class name here. It doesn't explicitly extend anything, and it doesn't appear to be specifically about Submarines, Substituion, Subtraction, Sublimation, or Subaru.
3. Why is ano public?
4. What does "ano" mean? What's the variable for? I should be able to at least guess at an identifier's meaning/purpose from its name.
5. There's never a need to import anything from java.lang.
6. It's generally better to import individual classes, rather than *, although in some shops there may be a standard to use * if you import more than N individual classes from that package.
7. Why are bal, in, name, and type not private?
8. Don't declare multiple variables on the same line (name, type).
9. The Sub() constructor is pointless. It only sets variables to the default values that they're already given before the constructor is even invoked. Get rid of it completely or give it an empty body.
10. It would probably be better to make name and type final, although without knowing more details about the larger context, I can't say for sure.
11. Rather than have getData() that queries the user, the user input should be handled in a separate class. That class should then either call new Sub(name, type) or create a blank Sub and call setters for name and type. (I prefer the former in general, but the latter is also valid, particular in an Dependency Injection context, such as Spring.)
12. Why is getData() package-private?
13. If the user doesn't provide a valid int input, the nextInt() call will throw an exception, which you're not handling. The program will just crash.
14. "j" is a poor variable name for the result of nextInt().
15. If the user provides an int other than 1 or 2 for the type, you print out an error message, but you don't do anything about it. You just end up with a Sub that has an invalid type.
There's more, such as the labeled loop, bad variable name "t", hardcoded "\n" for newline, not using equalsIgnoreCase(), "bank" class name starting with a lower case letter and being package private...
This sample code would not give me a good impression of a job candidate. That's not to say that someone who writes code like this couldn't get a job, and learn as he goes, but it would have to be for a very junior position and there would have to be quite a bit of mentoring or at least oversight and review.