This depends on an individual's taste and hence hard to decide if one is
better than the other.
>
> -- don't align field declarations by columns (it look really ugly and
> harder to read when there are mix of fields with short and long names,
> i.e. constants)
I kind of like the my field declarations to be aligned, I think that
makes it easier to read, thats jsut me !
> -- don't indent contructor, method call params and few other
> constructs on column (it also look quite bad wen parameters starts far
> from the left)
I dont have a strong opinion on this, but I like this
public ObjectManagerImpl(ObjectManagerConfig config, ThreadGroup
gcThreadGroup, ClientStateManager stateManager,
ManagedObjectStore objectStore,
EvictionPolicy cache,
PersistenceTransactionProvider
persistenceTransactionProvider, Sink faultSink, Sink flushSink) {
better than this
public ObjectManagerImpl(ObjectManagerConfig config, ThreadGroup
gcThreadGroup, ClientStateManager stateManager,
ManagedObjectStore objectStore, EvictionPolicy
cache,PersistenceTransactionProvider persistenceTransactionProvider,
Sink faultSink, Sink flushSink) {
To me the first one is more readable than the second.
>
> -- don't format line and block comments and don't indent those
> comments either
This I agree, especially block comments. Sometime commenting a block of
code and reformatting the source make the code all in one line and is
annoying as hell.
>
>
> See attached formatting settings
>
> Also, I'd like to suggest to not reformat code when working on
> issues. Commit all the functional changes and commit any reformatted
> code in a separate commit
The problem is that if you are working on 20 files for a fix, you are
not going to go back and make a new changeset just for formating those
20 files. It is much easier to do it then and there. I would much rather
look at diffs with formatting changes than code with no formatting.
cheers,
Saravanan
>
>
> regards,
> Eugene
>
>
> Tim Eck wrote:
>>
>> I committed new versions of all our .classpath files in trunk. I
>> wrote a program that uses modules.def.yml and the various ivy
>> dependency descriptors and generates .classpath for each module.
>>
>>
>>
>> Some of this effort might be redundant when and if we ever use maven
>> to drive our build, but that day is not today J
>>
>>
>>
>> I intend to also standardize the .settings files (ie. compiler
>> options, warnings, formatting, etc) across our eclipse projects as well.
>>
>>
>>
>> Let me know if this update breaks anything in eclipse.
>>
>>
>>
>> -tim
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> tc-dev mailing list
> [email protected]
> http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
