1) In creditCardType, you should probably be using string matching throughout to avoid your inputNChars variables, which are very smelly 2) Obligatory reminder to leave credit card handling to external libraries. In general, they'll simplify your code, but with credit cards in particular, not using standard libraries might make you liable if anything goes wrong and numbers get leaked. I assume this is a sample project, though, not actual production stuff.
–
raptortech97Aug 8 '14 at 18:50

1

You might want to wait longer before accepting an answer. 3 hours really isn't that much time, and you'll get more feedback - and possibly even better answers - if you wait.
–
WernerCDAug 8 '14 at 20:25

3 Answers
3

Comments

You're stating the obvious and forgetting the important things. Yes, args is the command line arguments, but that's standard for the Java main method. I'd suggest documenting which command line arguments you actually accept - namely only one, and it should be a file path!

Additionally, some of the code in the methods below looks like it could use some commenting as well. It looks complicated. Maybe I'll understand it if I look at it in greater detail...

Throw exceptions when it matters

From your validate function. This will throw NumberFormatException if it fails to convert the character to an Integer. But if you throw NumberFormatException, the whole program grinds to a halt! If you encounter an unparseable character in a creditcard number, then obviously it's not a valid credit card number. Wrap it with try-catch and return false.

Readability

When dealing with ranges, I prefer to write an if statement as a range, rather than two separate conditions. Consider if (16 <= str.length() && str.length() <= 19) instead. This goes for all cases where you have ranges like this.

Magic Numbers

Your third method is filled with magic numbers! What do 622126, 622925, 6011, 644, 649 and so on even mean?! In this case, I think they're all connected in some sort of way. You should add a comment in the code stating where you got the numbers from.

Other comments

java.lang.StringBuilder can take a String as argument. Doing so would allow you to remove your append call, shortening the code, making it more readable (and potentially speeding things up slightly as you need 1 function call less, but that's negligible).

This will return true even if the length of the number isn't correct for a CC number. The most obvious example being the empty string which will return true.
–
VooAug 9 '14 at 11:06

@Voo what do you mean by "This"? The validation algorithm? Check OP's question; they had the same flaw. I decided not to add a length check because the length check is not part of Luhn's, I believe. Additionally, it's caught in the second function, the one for getting the credit card type.
–
PimgdAug 9 '14 at 12:28

validate()

A validation function normally returns true, or false, but your function can also throw exceptions when there are illegal (non digit) characters, because of the Integer.parseInt(...).

Additionally, you can run Luhn's algorithm without the array.... and certainly without the reverse..... In fact, Luhn's is designed to run in-line, and not need to have any intermediate storage, which is why it is useful.

Can be replaced with the following method. You will notice that the if-logic has been entirely replaced with mathematics... allowing you to have just the one loop, and only the one valid-digit if statement. The three tricks are:

the multiplication by zero to avoid the double

the / 10 and % 10 to do the if double > 9 then double -= 9

the use of the Character.digit() function to perform the digit-to-integer parsing (without throwing the exception).

These are just examples. Add more, try to cover all corner cases. Tests like these make refactoring easy too: once you have passing tests for all corner cases, you can boldly go and refactor, knowing that if something breaks, you'll know it immediately.