2010-10-13, 12:37 AM
|
Getting into Java: French Verb Conjugation Program
|
|
2010-10-13, 12:54 AM
A few things I'm noticing:
In verbs.java, you have VERB and REG. It's generally not good practice to have variables be all uppercase letters. If I'm looking at code for any language and I see all uppercase letters, I'm going to be looking around for static, global constants. It's good practice to do this in any language. So change VERB and REG to verb and reg to avoid confusion. Another thing I like to steer clear of are try/catch exceptions. Unless you need to inform the user of a problem in the catch{} section or if there are multiple things that could go wrong, there is no need for a try/catch. Perform a string split, check the length of the array, and if it's the wrong length then tell the user what's up (if-else). Also, it's bad karma to have "verbs" be a method. A method must be a Noun+Verb and variables must be nouns. A method named "verbs" is confusing.
2010-10-13, 01:14 AM
You should probably look into the "switch/case" structure, it's ideal for this type of thing.
And even if you don't implement anything other than the present tense for now, you might want to structure your code with other tenses in mind. You might also want to consider (not saying this is a good idea) putting the endings into a static variable and then linking that back. Eg. PRESENT_ER = {'e', 'es','e','ons','ez','ent'} Then just passing that array back instead of combining the parts. Ex. verb.showVerb(PRESENT_ER)
2010-10-13, 01:37 AM
Fiel Wrote:A few things I'm noticing: At one point, I had "verb" and "reg" used in the constructor, so I used capitals to avoid confusion. Caps Lock = static global constants? Easy enough to remember. A length check before trying to get the second argument is a good idea. I'm not sure how I missed that. A verb without a noun is vague, so are you saying I should change "conjugate" to something like "conjugateVerb", class verbs to class theVerb, et cetera? Stereo Wrote:You should probably look into the "switch/case" structure, it's ideal for this type of thing. When I tried using switch/case, the IDE got mad at me for using strings. ![]() Tenses are another layer of complexity, but adding them sounds like a good idea. A static array would certainly make thinks look more organized and easier to change, but it makes me think of a bigger problem: Some verbs are regular in one tense but irregular in another. Factoring that into a single file of irregular verbs could get messy....
2010-10-13, 01:55 AM
Hazzy Wrote:A verb without a noun is vague, so are you saying I should change "conjugate" to something like "conjugateVerb", class verbs to class theVerb, et cetera? It should be ConjugateVerb, although "Verb" here is redundant. Using the IDE, you'll know you have to pass a verb in, and it's fairly obvious what the method does. Variables should be lowercaseUppercase Methods should be UppercaseUppercase Global constants should be UPPERCASE Tenses aren't too bad to deal with, but you should have caution now. You do not want to mix data and code as it becomes an unmanageable mess. I don't even like the fact that you have to pass in "irreg" to the command line. Ideally, the user has no fricken clue how to conjugate the verb, and, as such, should not need to know that the verb is irregular. Also, there are some tenses which are irregular for verbs and others which are not. This sounds complicated at first, but once I explain this to you, you should be able to figure out how to do it with some ease. The idea for how to solve this problem is to create something called a datastore or persistent object. This is a file on your computer - like the WZ files - that remembers data. So, since you have verbs, and each verb HAS A conjugation type, and each conjugation type HAS A list of conjugations, knowing how this works will help you out. So... Verb --> tense --> list of conjugations With each verb requested for a list of conjugations, you look up in the datastore to see if the verb/tense paring is irregular. If it returns nothing, then conjugate it normally. If it returns a list, then show the list instead of conjugating. The real hassle for you is going to be how to create the datastore. If I were you, I'd do it like this (this is in spanish, but you can figure it out): Code: [ir,present]
2010-10-13, 02:15 AM
That concept of a datastore that you described is what I was going for with a text document for irregular verbs. The end goal of this program is to provide practice for people who know the verbs to an extent, so it should not be unreasonable to expect that people will add verbs to the 'irregular list'. (saves me the trouble of adding EVERY French verb to the list) Editing a text file to add a verb and its conjugations is something most people can do. On the other hand though, making a second program / option to add to a datastore that is saved in a more complex, harder-to-break format might be easier for users who use computers for nothing more than email.
Extrapolating your example, it would look something like this? Code: etreCan datastores be text files or do they have to be more complex? I'm Googling around to find out more on datastores, and I see jargon galore.
2010-10-13, 02:24 AM
A datastore is nothing more than data which is saved when the program dies. It's as simple as that. You don't need a hearty amount of encryption for this. Think about it. Are you gonna be mad if someone views your datastore? Likely not. You want people to view it and freely edit it. The end user has no benefit of changing the files except for his or her own benefit, so it doesn't serve to encrypt the document.
You can use anything your heart desires for a datastore. As long as it stays consistent and is easy to edit, update, and query, I really don't care what you use. If you're going with the INI files, I recommend going against what you have there. Each section must be unique to query it which is why I used [etre,present] so that every section is unique.
2010-10-13, 05:57 AM
In the case of irregular verbs, you'd either want to store them as the 'stem' (et for etre, all for aller) or, better change your verbs(input) function so it doesn't immediately cut it down to the root. That should be happening during conjugation anyway, in terms of code that makes sense.
If you want to make this useful in an easy way, have it flash up IL ALLER (imparfait) > Then the user types in "il allait" and it says "bon travail!", or they put in "il alle" and it says "non! le correct reponse est: il allait"
2010-10-13, 08:47 PM
Reading from files is something I have not done a lot of, so I will have to look around a bit on how to do that. Before I start playing with that, however, I want to make sure the rest of my program is solid. (Or at least promoting good habits)
I went through my code and rewrote it to be more organized. I changed some names. I changed how the information is stored - instead of storying the conjugated verb in an array, I have a function return the conjugated form of the verb given a pronoun input. tense and infinitive are set as final variables that are defined during the object's creation. Imperfect verb endings are independent of the verb type, so I have the method check for type only if tense is present. If no tense is entered, the program defaults to present. I think that's the basis of what I changed. I have been working on and off of this for the past few hours so my memory is a bit foggy. I tried to hit everything you guys mentioned, but I might have missed something.
LesPommes.java
Verb.java
The current ini file I have laid out to use (but do not use yet):
Spoiler
Aller is only irregular for the singular pronouns, in the present, so when the program tries to look up plural pronouns, it should return nothing and continue on with regular conjugation.Adding accents where they belong is something I should do too.
2010-10-13, 08:53 PM
I'm curious, Fiel, what data format would you use for the datastore in memory? If the file's static you could just stick it all into a hash table (key = verb, tense, pronoun), but they're not great on sequential writing back to file. Or if it was bigger you could go fullblown database, like sql or something. Or then again, just do it up in a tree of some sort.
2010-10-13, 11:43 PM
Fiel Wrote:Variables should be lowercaseUppercase My programming style are: SomeClass for class name, function_name for function. As for variables, I usually do var_name. Constants are uppercase as you stated. Alternatively, the function/method name start with lower and then Camel case after, eg thisIsAnExample. I exclusively have full camel case for class name only. Ideally, you may want to have something like ClassName, variable_name, functionName so you can easily distinguish between them, tho some people hate underscores. Another style many unix programmers tend to do is to have _classVariable for classwise variables. For the above case, you could have _verb for the class variable and verb for the function input. I used to do this, however, you may get collisions with some predefined variables, since most variables that are system related usually start with __ (2 underscores). To avoid the confusion, I usually lable my variables as input_verb (for the input of the function), clean_verb after you sanitize it.
2010-10-14, 12:17 AM
@Stereo - Linked List - though I'm sure Java has its own INI reading facilities given .properties files.
@Gummy - can't you just put the underscores after the variables? @Hazzy - an empty for loop?
2010-10-14, 12:57 AM
I saw it used somewhere, it might have been a C++ book. It loops forever. while (true) would have had the same effect.
Edit: Google'd it. I put it there so I could test multiple verbs without restarting the program.
2010-10-14, 01:02 AM
Hazzy Wrote:I saw it used somewhere, it might have been a C++ book. It loops forever. while (true) would have had the same effect. Code: Verb MyVerb = new Verb(infinitive, tense);And for infinite loops that depend on user input, a do-while statement is strongly advised.
2010-10-14, 01:06 AM
Oh, that. I have no idea. I cannot think of anything that I used back to back loops like that for. Just a typo, I suppose.
2010-10-14, 07:45 AM
Fiel Wrote:Also, it's bad karma to have "verbs" be a method. A method must be a Noun+Verb and variables must be nouns. A method named "verbs" is confusing. Must not be "verb" or "Noun+verb". These are "noun"-functions you can use on ArrayList, made by Sun(/Oracle): size hashCode iterator listIterator subList "Noun"-functions you can use on String: hashCode length subSequence substring Not saying it's bad practise to use "verb", but you should rather have a short function-name that describes what it returns/does efficiently. Fiel Wrote:Variables should be lowercaseUppercase That is highly dependent on the programming language you use. When you're using Java, this is wrong convention. This is the standard Java-convention: classes - TheClass variables - theVariable function - theFunction static variables - THE_VARIABLE static function - theFunction final variable - THE_VARIABLE
2010-10-14, 09:33 PM
Also, I made an effort to never use plural names. I'd do something like verb_list over verbs.
2010-10-20, 06:18 PM
I have been working on and off of this, and I have run into a bit of a problem. I want a command "exit()" or close out of the program. It just seems more elegant than the little "x" in the terminal / command prompt window. I did this by having two loops: One that continues as long as a boolean "isRunning" is true and one that runs forever. When the user inputs "exit()", it calls a function that sets isRunning to false and then breaks the second loop. I gets the job done, but I feel like there should be a more elegant way to do this.
I also added support for an ini file. I focused more on making it work, so I ended up downloading a library off of the Internet because the syntax was a lot simpler than the walls of jargon I found on other sites. In retrospect, this seems like bad practice. So right now I have two concerns: 'Proper' INI management and an elegant way to exit the program. Verb.java
Spoiler
LesPommes.java
Spoiler
verb_list.ini
Spoiler
2010-10-20, 06:53 PM
When dealing with user input, a do-while is best.
Code: do{For the INI file, put the try/catch in the constructor so that it's only loaded once for the entire conjugation process. As it stands, you're loading it 6 times for every verb. Something else that I"m noticing is that you're calling the conjugate method 6 times to get all 6 conjugations. Ideally, from outside the object, other objects don't need to know that there are six types of conjugations. What if you want to add or subtract conjugations later? Just call conjugate once and let the loop in conjugate take care of it. Make it return an array, then tell your main method to loop through the array and print it out. As an additional level of complexity, try adding the following features: - Conjugation of reflexive verbs (se marier) - Ability to conjugate in multiple tenses at the same time (se marier present pastperfect)
do-while looks and reads better.
Check for legal tense right after it test for length. I can easily update the tense list without having to fiddle with this part. This will make it easy to support both English and French tense names. Code: boolean matchFound = false;I am not entirely sure how to conjugate reflexive verbs because we have not gotten there yet, but that should be just a Google Search or two away. Dual conjugation would be cool, but towards my goal of flash cards I am not sure it would be useful. |
|
« Next Oldest | Next Newest »
|
Users browsing this thread: 1 Guest(s)


