Return to Answer

Your lines are very long. There are good reasons to stick to an 80 char limit.

I like your use of interfaces. Interfaces can be very helpful.

You seem to be on the right track with making your code modular. Most of the classes are short and concise.

There are a few comments detailing what the methods do. BinaryFormatter for example, needs little or no explanation. InstructionToBinaryConverterInstructionAImpl. getBinaryRepresentationForInstruction can use a little explanation. The extra long name describes the expected outcome of using the method, but it contains no mention of how it is accomplishing the task. It seems you can get away with something like

 // Converts an instruction into binary form; depending on
 // instruction type. If instruction is a symbol, and the symbol is not
 // known, adds symbol to the local HashMap field lookUpMap.
 @Override
 public String representInBinary(Instruction instruction) { }

This is a lot of files. I spent a good ten minutes organizing each file into my IDE. I think next time you ask for a code review you should keep the code much shorter; and post only the files you are concerned about.

Your lines are very long. There are good reasons to stick to an 80 char limit.

I like your use of interfaces. Interfaces can be very helpful.

You seem to be on the right track with making your code modular. Most of the classes are short and concise.

There are few comments detailing what the methods do. BinaryFormatter for example, needs little or no explanation. InstructionToBinaryConverterInstructionAImpl. getBinaryRepresentationForInstruction can use a little explanation. The extra long name describes the expected outcome of using the method, but it contains no mention of how it is accomplishing the task. It seems you can get away with something like

 // Converts an instruction into binary form; depending on
 // instruction type. If instruction is a symbol, and the symbol is not
 // known, adds symbol to the local HashMap field lookUpMap.
 @Override
 public String representInBinary(Instruction instruction) { }

This is a lot of files. I spent a good ten minutes organizing each file into my IDE. I think next time you ask for a code review you should keep the code much shorter; and post only the files you are concerned about.

Your lines are very long. There are good reasons to stick to an 80 char limit.

Regarding your comment:

What is Jitter :)

After some searching, I came across this page, which describes a tweet-like service for "things". I also critiqued a post containing the same exact Jitter class. Concerns raised in the responses to that post may prove helpful.

I like your use of interfaces. Interfaces can be very helpful.

You seem to be on the right track with making your code modular. Most of the classes are short and concise.

There are a few comments detailing what the methods do. BinaryFormatter for example, needs little or no explanation. InstructionToBinaryConverterInstructionAImpl. getBinaryRepresentationForInstruction can use a little explanation. The extra long name describes the expected outcome of using the method, but it contains no mention of how it is accomplishing the task. It seems you can get away with something like

 // Converts an instruction into binary form; depending on
 // instruction type. If instruction is a symbol, and the symbol is not
 // known, adds symbol to the local HashMap field lookUpMap.
 @Override
 public String representInBinary(Instruction instruction) { }

This is a lot of files. I spent a good ten minutes organizing each file into my IDE and came up with:

I think next time you ask for a code review you should keep the code much shorter; and post only the files you are concerned about.

Your lines are very long. There are good reasons to stick to an 80 char limit.

I like your use of interfaces. Interfaces can be very helpful.

You seem to be on the right track with making your code modular. Most of the classes are short and concise.

There are a few comments detailing what the methods do. BinaryFormatter for example, needs little or no explanation. InstructionToBinaryConverterInstructionAImpl. getBinaryRepresentationForInstruction can use a little explanation. The extra long name describes the expected outcome of using the method, but it contains no mention of how it is accomplishing the task. It seems you can get away with something like

 // Converts an instruction into binary form; depending on
 // instruction type. If instruction is a symbol, and the symbol is not
 // known, adds symbol to the local HashMap field lookUpMap.
 @Override
 public String representInBinary(Instruction instruction) { }

This is a lot of files. I spent a good ten minutes organizing each file into my IDE. I think next time you ask for a code review you should keep the code much shorter; and post only the files you are concerned about.

Your lines are very long. There are good reasons to stick to an 80 char limit.

I can't make heads or tails of the Jitter class. You set a thing and a place; you have some repeating code; there are no comments to quell my confusion. Now that I think of it, I saw what looks like same exact file on this post. Is this some incomplete demonstration code?

I like your use of interfaces. Interfaces can be very helpful.

You seem to be on the right track with making your code modular. Most of the classes are short and concise.

There are a few comments detailing what the methods do. BinaryFormatter for example, needs little or no explanation. InstructionToBinaryConverterInstructionAImpl. getBinaryRepresentationForInstruction can use a little explanation. The extra long name describes the expected outcome of using the method, but it contains no mention of how it is accomplishing the task. It seems you can get away with something like

 // Converts an instruction into binary form; depending on
 // instruction type. If instruction is a symbol, and the symbol is not
 // known, adds symbol to the local HashMap field lookUpMap.
 @Override
 public String representInBinary(Instruction instruction) { }

This is a lot of files. I spent a good ten minutes organizing each file into my IDE and came up with:

I think next time you ask for a code review you should keep the code much shorter; and post only the files you are concerned about.

Your lines are very long. There are good reasons to stick to an 80 char limit.

Regarding your comment:

What is Jitter :)

After some searching, I came across this page, which describes a tweet-like service for "things". I also critiqued a post containing the same exact Jitter class. Concerns raised in the responses to that post may prove helpful.

I like your use of interfaces. Interfaces can be very helpful.

You seem to be on the right track with making your code modular. Most of the classes are short and concise.

There are a few comments detailing what the methods do. BinaryFormatter for example, needs little or no explanation. InstructionToBinaryConverterInstructionAImpl. getBinaryRepresentationForInstruction can use a little explanation. The extra long name describes the expected outcome of using the method, but it contains no mention of how it is accomplishing the task. It seems you can get away with something like

 // Converts an instruction into binary form; depending on
 // instruction type. If instruction is a symbol, and the symbol is not
 // known, adds symbol to the local HashMap field lookUpMap.
 @Override
 public String representInBinary(Instruction instruction) { }

This is a lot of files. I spent a good ten minutes organizing each file into my IDE and came up with:

I think next time you ask for a code review you should keep the code much shorter; and post only the files you are concerned about.