Content:
In the previous post, we installed Checkstyle and tested it a bit, a little proof-of-concept, useful for your little project at home, it doesn't cares anybody, and the world could survive without it perfectly.
Now focus on your company, it is unforgivable that every mate format their code as Sant Peter tells them. You implanted CheckStyle code in your I.T. dept. and it looks like better, but Sun style (default one for Formatter and CheckStyle) doesn't fit your interests.
One example. Your monitor is 1280 pixels wide, but Formatter defaults to 80 columns of text, and you find it miserable for your hardware, that supports much more, at least 120 columns.
Let's build this example, a comment of 143 columns length.
As soon as you invoke Formatter (Ctrl+Shift+F or Menu Source->Format), the result is next:
The comment line was broken at column 79, but I spent a large amount of money in a extreme-wide monitor and I find that length ridiculous. I better change this parameter.
Check your configuration in Window menu -> Preferences -> Java -> Code Style -> Formatter. The best you can do in this point is create your own profile, based on an existent one.
I chose New ... and type anavarro_prof, based on "Java Convention [built-in]"
Then, edit your new profile, as a sample, we will change line width...
and comment width...
Once both parameters are changed, let's suppose your project is using the IDE default formatter, so, your formatter, that have been chosen as default one after its creation.
Return to your code, re-format it! it works! it has been formatted to 120 lines width.
Did it work? not completely... see that magnifying glass that appeared at the left side of your comment...
Line is longer than 80 characters?. What's up?
This is happening because your Formatter is not directly connected with your CheckStyle plugin, so you will have to transmit your Formatter changes into your CheckStyle configuration.
Open Window Menu -> Preferences -> CheckStyle.
You should find the two built-in configurations, but you want to configure your own.
So firstly select one of them, click "Copy" to create a configuration based on an already created one.
And change some parameters, as the type, make it external, change that ugly name and select a location where the new configuration will be created. I lend you an example:
Then, clicking "OK", your new configuration will be created and you can both "Set as Default" and "Configure". Yes, please, "Configure" it.
Search for "Maximum Line Length", and EDIT existent "Maximum Line Length" in the window on the right. Beware don't add an additional property already existent, because you won't get the desired goal.
Then change its maximum length doubleclicking it:
Save, Ok, Rebuild, do whatever neccesary to get your code window again, magnifying glass should dessapear after recompiling. Mine does! You have also got an external CheckStyle configurer as a xml file where you asked to. This file will be transferred to your mates in next chapter.
Quite a long article, you should have learned to customize your Formatter and make your CheckStyle configuration being Formatter-compliant. You can now impose both configurations to your entire team, in the next article, promise.
Have a happy New Year's Eve!!!
This blog is written for teaching about Java technologies and best-practices. I will talk about patterns, Maven, J2EE, Artifactory, Hudson, Sonar, and so on.
Suscribirse a:
Enviar comentarios (Atom)
Etiquetas
maven
logstash
vrr
logback
json
matrix
artifactory
cis
configuration
CheckStyle
developers
devops
filebeat
ops
elasticsearch
importance
installation
java
priority
severity
tomcat
SpringSource
book of the month
critical
debug
important
log
low
plugin
What if
code repository
curator
dependencies
essential readings
essentials
structured arguments
Eclipse
Formatter
Tunning
apache
basic
best practices
codegen
continuous deployment
continuous integration
contract-first
deploy
gradle
jenkins
kibana
lombok
manager
nexus
opinion
performance
persistence
pom.xml
slf4j
storage
svn
testing
401
409
ChekStyle
Error
Homogeneous
JavaMelody
Managing
Monitoring
Scrum
Solution
Style
Trenches
XP
advantages
algorithm
ansible
architecture
aws
bitbucket
cabotrafalgar
cd
chargers
cheap
chef
ci
comparison
cons
cow
cvs
dependences
disk
distribution
docker
docker-compose
documentation
eb
ecs
elastic
elk
ender's game
enforcing
essential tools
estimation
external
fail
findbugs
folders
git
github
grok
html
hudson
ide
inheritance
javadoc
jcl
jmr
jmx
kv
libvirt
lifecycle
load
log4j
logbacl
logger
low cost
mdc
memory
multiple files
mysql
nature
nifty-gui nifty-flow
organization
permissions
pmd
pragmatic programmer
profiles
pros
puppet
q outside the office
release
remote
reporting
save
security
several files
simulated annealing
site
snapshot
sonar
standard
strategies
stress
suppressions
surveillance
tale
throughput
unit
upload
usvn
vagrant
versioning
war
wires
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.