make camel case consistent in class and method names

mkabbasi / cleartk

Automatically exported from code.google.com/p/cleartk

0 stars 0 forks source link

make camel case consistent in class and method names #322

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago

We should decide whether or not acronyms that are found in class names should 
be changed to conform to a more standard camel casing for class names.  For 
example, LIBSVMClassifier would become LibsvmClassifier.

Original issue reported on code.google.com by phi...@ogren.info on 4 Aug 2012 at 4:35

GoogleCodeExporter commented 8 years ago

Original comment by phi...@ogren.info on 4 Aug 2012 at 6:07

GoogleCodeExporter commented 8 years ago

Original comment by lee.becker on 17 Feb 2013 at 6:01

Added labels: Milestone-1.4
Removed labels: Milestone-1.3

GoogleCodeExporter commented 8 years ago

Original comment by steven.b...@gmail.com on 3 May 2013 at 9:15

Added labels: Milestone-2.0
Removed labels: Milestone-1.4

GoogleCodeExporter commented 8 years ago

This is a backwards incompatible change that we've decided to take care of.  
Note that we aren't very consistent in our current naming such as 
org.cleartk.examples.pos.

Original comment by phi...@ogren.info on 23 Jul 2013 at 5:15

Changed title: make camel case consistent in class and method names
Added labels: backwards-incompatible

GoogleCodeExporter commented 8 years ago

I started this issue.  It seems fairly straightforward for the most part.  I 
created a test called CamelCaseTest in cleartk-test-util that goes through the 
top-level directory and looks at all .java files for names with to consecutive 
upper case letters.  This isn't a perfect test because there are some file 
names that have single letter "words" in them such as XWriter and 
TempEval2010TaskAAttributes.  I think I will just add a list of exclusions.  

I am motivated to get this done very soon as merging these changes into a 
changed master branch is likely to be rather painful.  Hopefully tomorrow....

Original comment by phi...@ogren.info on 5 Aug 2013 at 4:12

Changed state: Started

GoogleCodeExporter commented 8 years ago

I have checked in all my changes to branch Issue-322.  

This issue is pretty much done except that many of the TimeML (er... TimeMl) 
models have old class names in their manifest files (e.g. LIBLINEAR*).  So, the 
models either need to get rebuilt or updated.  I updated a couple of them by 
hand but I don't have an efficient way of doing it and it was tedious.  

Steve, I am reassigning to you hoping that you can either rebuild the models or 
tell someone (me?) how to build them.

Original comment by phi...@ogren.info on 6 Aug 2013 at 3:39

GoogleCodeExporter commented 8 years ago

Original comment by phi...@ogren.info on 6 Aug 2013 at 3:41

GoogleCodeExporter commented 8 years ago

So your Issue-322 commits seem to have been lost. I can see CamelCaseTest on 
Google Code:

https://code.google.com/p/cleartk/source/detail?name=e8b6d5540f22&r=e8b6d5540f22
0c39e03106b64a0c3b923685ada8

But any way I try to access that via git fails. So my plan is just to take the 
last version of CamelCaseTest and then correct everything again by hand.

Original comment by steven.b...@gmail.com on 25 Oct 2013 at 5:34

GoogleCodeExporter commented 8 years ago

Fixed in revision b83b835cbe3aee776400dd2dc103aeb313ff3572, with test added in 
revision 71945ad46f815b49a3cea77a2d0b71dba85a4fbd, and TimeML models retrained 
in revision fafacdc7bfcf922531e91e174462a48185e18812.

Original comment by steven.b...@gmail.com on 25 Oct 2013 at 8:53

Changed state: Fixed

GoogleCodeExporter commented 8 years ago

Thanks for taking care of this.  Sorry for the extra trouble.  I am clearly not 
up to speed with git yet or this sort of thing wouldn't happen.

Original comment by phi...@ogren.info on 25 Oct 2013 at 10:08