On these screenshots, you can see the difference between indent size.
The first one it's the default Code Style provided by Idea:
And the second one it's a Google Java Code Style (I renamed it a little but it's the same default file):
The second screen clearly shows that the indents a smaller in a half.
What's the point in reducing them? And the second question is, how can I undo this modification by modifying the file?
To allow long lines become shorter to make more free room on small screens.
The original 4 spaces indentation was intentionally introduced with the design of java (whereas the indentation of C/C++ was normally less), for a better overview and in order to punish too much nesting of blocks, using more sub-methods. And indeed this indentation does not hurt.
Google's later Java code style is an actionistic reform, which such a huge player like Google can push.
For a regular indention of code of 4 indents it would save only 8 characters.
This has minor effect when also considering the length of field/variable/method names.
So I would call the Google style hubris, a mistake for a language which has strong conventions. Other languages have more variations, especially on placement of parentheses and on spacing.
But one should adapt to the convention of the one of both, that is used in the firm. Google's style did not generally replace the old style, even though Android is a huge part on Google's home turf.
Related
I'm doing project at University right now where I have to develop a word learning/translating game where multiple clients compete to translate a words the fastest, handled by a central server.
The GUI for this uses Java Swing JFrames, and to get a good looking GUI with nicely placed texts and buttons and such, you need a lot of specific numbers for distances and widths and such.
Now my Professor is VERY strict about checkstyle-violations, and she provides her own checkstyle-files, which include checks on magic numbers...
Now a pretty simple code fragments with 2 methods (of 20) such as:
private void addLanguageText() {
languageText = new JLabel();
languageText.setText("Sprache auswählen:");
languageText.setBounds(20, 70, 150, 30);
frame.add(languageText);
}
private void addWelcomeText() {
welcomeText = new JLabel("Willkommen zum Lernspiel!", SwingConstants.CENTER);
welcomeText.setFont(welcomeText.getFont().deriveFont(20.0f));
welcomeText.setBounds(0, 10, 500, 30);
frame.add(welcomeText);
}
Already has 8 different magic numbers, so my checkstyle warnings have about 100 entrys for magic Numbers in total.
Now it seems pretty impossible to just add 100 number constants, escpacially since they would have to have names such as WELCOME_TEXT_LEFT_BOUNDS.
What would be an efficient solution for dealing with this?
There's two solutions to this problem: either pull every value out to a constant (which you stated would be unreasonable), or base those values on other, more universal, constants.
For example, in order to have a welcome text in the middle of the screen, halfway down, you could write something like:
welcomeText.setBounds(0, SCREEN_HEIGHT / 2, WELCOME_TEXT_WIDTH, WELCOME_TEXT_HEIGHT);
This solution, however, is effectively similar to using a LayoutManager, albeit with a bit more customizability. There really isn't any, reasonable, way to remove all the magic numbers, but you can hide them behind math or external libraries.
Edit for clarity:
Pulling out all of the magic numbers to their own constant isn't a good solution because doing so takes a long time and heavily limits the usability of your code in non-standard situations, hence why I recommend using a LayoutManager (or a self-made variant if you want to put in extra work). To emphasize, though, a LayoutManager does not remove magic numbers, they simply hide them from view. Visual interfaces usually don't use exact fractions of the screen, for aesthetic appeal.
Use layout managers. This way, your interface will not only be (almost) free of magic numbers -- it will also work as expected when windows are resized, or text suddenly takes more or less space than it used to (this happens often when you translate an app from one language to another).
In particular,
JFrames almost always benefit from a BorderLayout
GridBagLayout can take care of anything (but it is a hassle to learn at first). Nested BoxLayouts are easier to learn and use.
Simple popup dialogues can be built very easily using JOptionPanes, which include their own layout for accept/cancel/... buttons.
Remaining magic numbers should be things like "number of columns in this dialogue" or "uniform spacing used to separate form rows", and can be given meaningful constant names.
With layouts, you never need to call setBounds directly. Several widespread IDEs have built-in graphical support for playing with layouts, so do not need to dive as deep in the documentation as it may seem. I recomment NetBean's form editor.
I'm trying to find if a scanned pdf form contains a signature (like making sure a check is signed).
The problem domain:
I will be receiving document packages (multi page pdf's with multiple forms). I have already put together document package classifiers that will check the package for all documents and scale the images to a common size. After that I know where the signatures should be and can scan the area of the document specifically. What I'm looking for is the best approach to making sure there is a signature present. I've considered just checking for a base threshold of dark pixels but that seems so clumsy. The trouble with signatures is that they are not really writing, more of a personal mark.
The only thing I can come up with is a machine learning method to look for loopyness? But I'm not all the familiar with machine learning and don't even know where to start with something like that. Anyone with some suggestions for practical approaches would very appreciated.
I'm coding this in Java if that's helpful at all
What you asked was very broad so there isn't a lot of information that we can give you. However, I can point you to some helpful links:
http://java-ml.sourceforge.net/ --This is a library that you can download that has lots of useful algorithms and other code to include in your program
https://www.youtube.com/playlist?list=PLiaHhY2iBX9hdHaRr6b7XevZtgZRa1PoU --this is a series that explains neural networks (something you might want to look into for your machine learning)
So a big tip I have for your algorithm is to instead of looking for how long exactly all of the loops and things are, look at all of their relative distances
"Relative distances from what?" you say. Well this is where the next tip comes in handy: instead of keeping track of the lines, keep track of the tips of the loops and the order of these points. If you then take the distance between all of them (relatively of course which means to set one of the lengths to zero). Along to keeping track of the distances, you should also keep track of the angles. You would calculate the angle ABC by taking the distance between (A,B), (B,C), and (A,C) (A,B, and C being coordinates on the xy plane) which creates a triangle between the points which allows you to use trigonometry to calculate the angle.
(I am assuming that for all of these you are also trying to detect who's signature it is of course because it actually doesn't really complicate things much at all) When trying to match up the signature detected to the stored signatures to see if they are the "same," don't make it to where the distances and angles have to be exact. Give a margin of error (like use a % range above and below). Here is a tip: Make the margin of error rather large. That way if it is written poorly, it will still be detected. This raises the chances of more than one signature being picked up. Luckily, there is a simply solution to this. Just have it run the algorithm again on the signatures that were found but with the margin of error smaller (you of course don't do this manually, the program does it). Continue decreasing the margin of error until you get only one signature remaining.
I am hoping you have ideas already for detecting where the actual signature is but check for the difference in darkness of the pixels of course. Make sure it is pretty continuous. Also take note of the fact that signatures are commonly signed in both black or blue or sometimes red and other fancy colors.
Relatively simple question. I need to translate/localize a legacy Java application.
Our company, with newer applications uses .properties files in Java for localizing their strings, and this concept is very similar to .resx files in C# (which we also have products using that).
The problem is this is a legacy product that was around before we started thinking about localization. It is full of hard coded strings and also various forms of hard-coded string concatenation/formatting.
As far as I am aware I have a very daunting task of pulling all our strings and formatting into .properties files in the product and then referencing those in the code.
Personally I have no huge issue doing this work, but I want to make sure I am not missing something.
So I have a couple general questions.
Is there a faster way of converting my product to use the
.properties files? Off the top of my head I could write a script
that would automate maybe 30-40% of the work...
Are there any "gotchas" I should be worried about specific to converting a legacy
product (I am not looking for general localization "gotchas" which I
can google for, but anything specific to this scenario)?
Finally, are there any completely different strategies I am overlooking for
localization? This is just how we translate our existing products,
but because this is a legacy product (and on the agenda to be
re-written) this is essentially throw-away code and I could do pretty much whatever I want. Including just
finding the cheapest dirtiest fastest way possible, although I am
obviously leaning toward doing the job properly.
Any thoughts, people?
As a guideline I would say try to keep answers focused on the questions being asked, but any informational contributions or questions are always welcome in comments.
No, there is no faster way. You have to go through the code line by line.
There are plenty of gotchas, since internationalization is about more than just string constants.
You may already know that number formats and date formats need to be localized, but you'll need to be on the lookout for numbers and dates being embedded into strings via concatenation or StringBuilder.append calls. You'll also need to be on the lookout for implicit toString() calls, such as when a Number or Date is supplied as a Swing model value (for example, returning a Number from the TableModel.getValueAt method), or when a JSP or JSF EL expression refers to such a value directly instead of formatting it.
Similarly, keep an eye out for enum constants directly displayed to the user, implicitly invoking their toString() method.
Creating sentences through string concatenation is a problem not only because of the formatting of numbers, dates, and enums, but also because other languages may have different ordering of sentence structure. Such string concatenation should be replaced with localized MessageFormats.
Keystrokes need to be localized, including all mnemonics (and accelerators if it's a desktop app).
Layouts are an issue. Places where the application assumes left-to-right orientation are something you'll want to address; even if you're only planning to localize for other left-to-right languages, you probably know that putting off good i18n practices is asking for trouble later down the line.
If your app is a Swing application, you'll want to convert LEFT/WEST and RIGHT/EAST layout constraints to LINE_START and LINE_END. If your app is a web application, you'll need to factor out margin-left, margin-right, padding-left, padding-right, border-left, and border-right (and probably many others I'm forgetting) into lang-specific CSS blocks.
Swing apps also need to call applyComponentOrientation after building each window, usually right before calling pack().
Some programmers like to store parts of a UI in a database. I'm not talking about user content (which you shouldn't localize); I'm talking about label text, window titles, layout constraints, and so on. I have a hearty dislike for that practice, personally, but people do it. If your app is doing that, I guess either the database table needs a locale column, or the practice of storing the UI in the database needs to be removed entirely.
To answer your final question, if there are any better strategies than stepping through the code, I've never heard of them. You could just search for double-quote characters in the code, of course. I suppose the choice depends on how professional and polished your superiors want the application to look.
One thing I've learned is that throw-away code often isn't. Don't be surprised if that rewrite ends up trying to salvage large swaths of code from the legacy version.
After running Sonar on one of my project I get a violation for 'trailing comments'. So I wonder, is this purely related to accepted/recommended code layout conventions for Java or is there 'more to it'? What's the reasoning behind it? When I'm looking over some C++ code ( recent Doom code review, there are tons (or binder full of) trailing comments.
From the famous book Code Complete:
The comments have to be aligned so that they do not interfere with the visual structure of the code. If you don't align them neatly, they'll make your listing look like it's been through a washing machine.
Endline comments tend to be hard to format. It takes time to align them. Such time is not spent learning more about the code; it's dedicated solely to the tedious task of pressing the spacebar or tab key.
Endline comments are also hard to maintain. If the code on any line containing an endline comment grows, it bumps the comment farther out, and all the other endline comments will have to bumped out to match. Styles that are hard to maintain aren't maintained.
Endline comments also tend to be cryptic. The right side of the line doesn't offer much room and the desire to keep the comment on one line means the comment must be short. Work then goes into making the line as short as possible instead of as clear as possible. The comment usually ends up as cryptic as possible.
A systemic problem with endline comments is that it's hard to write a meaningful comment for one line of code. Most endline comments just repeat the line of code, which hurts more than it helps.
Having said that, it's also about one's choice about coding style. I would personally avoid trailing comments as they don't help that much.
Just because something has trailing comments doesn't mean they're good. Also bear in mind that Doom 3's code is ~10 years old, and coding styles change over time.
In general, trailing comments indicate that a line of code cannot stand on its own. And, in general, that's a code smell, because a single line of code should be fairly transparent.
Looking through some of the source I don't actually see a ton of trailing comments, though I see a lot of methods that are too long, and a lot of comments in the middle of functions.
Those often indicate the following code deserves its own method.
I would argue that yes, there's more to it, and the "more" is communication and clarity.
Trailing comments are nothing bad per se. However, you should write your code as clearly as possible so that you don't have to explain your code line by line using comments. That's why some people consider trailing code comments as a hint that the code is not understandable enough.
See also the Java Style Guide for more information about that.
This is a design question involving both Java and MySQL.
The client requires the addition of 14 boolean flags (T/F) to keep track of some new information in an existing class/table.
I can add these flags to the existing table, or I could create a new class and table just for this data. Adding the 14 boolean flags to the existing table will give it quite a few attributes, which I'm inclined to avoid (especially if the number of flags increases in time). Creating a new class/table is cleaner, but it it really necessary in this case?
Alternately, I could use a 16 bit integer with masks to multiplex the data and then I'm only adding one variable to the existing class/table.
My primary question is this: is it more efficient to store 14 individual boolean variables in a MySQL database and load them into the class, or would it be better to store a single integer and then (in Java) multiplex the flags using bit manipulation (i.e. masks)?
Secondary question, if individual flags are more efficient, then is it better to have lots of attributes in one table or split them? What is the penalty for storing lots of boolean flags in a table that already has quite a few entities?
If the primary question's answer is "integer + multiplex" then the second question becomes moot.
Thanks.
-R
I personally like to have separate columns. the only place I might consider masking is when the database and the application are running under extreme conditions or on low memory and storage devices where any use of memory or space is crucial.
1- space should not be a consideration unless the class/table can grow to huge volumes.
to simulate Boolean flags a tiny int (1) is enough and all you need is 0/1 values.
2- it becomes much harder for anyone wanting to do queries on the table or wanting to write reports using it. and if your client does access the database, I am quite sure masking won't be acceptable in most cases.
3- it will be much harder to build indexes on this column when they are needed, if that will be possible at all (based on the database)
4- working more and writing more code should not be an issue. You work more now but you will work less in the future. thinking it is less work for the programmer/dba is just an illusion IMHO. here are some considerations:
a- it will be harder to maintain the code and write database queries. maybe you do everything in your java code now but you never know what the future holds.
b- making structural changes become harder. what if the customer requires removal of two flags and addition of 4 ? do you keep the original two bits that held the removed flags in the database and add 4 bits ? or you use them for two of the new flags and then add two more bits? how would this affect code that is already written ? and how easy would it be to track all places and actually making the changes in the code?
in a small application, this is not a big problem. but applications grow with time. if the table gets to be widely used, this is very dangerous. if you had code working with the 7th and 8th flag, and they were removed and the decision was (by some other programmer lets say) to reuse the same places, any code that used to access the 7th and 8th bit will keep functioning (incorrectly) until that is noticed. it could already do harmful things until the issue is spotted and fixed. if you had separate columns and you dropped them, the error will pop up to the surface on the very first use of that code as the columns won't be there.
c- it will without a doubt be harder to make scripts that upgrade the data and/or change structure for the dba. an experienced dba will not sit and write the column names one after the other and will use its tools to generate scripts. with bit manipulation, he will have to work by hand and make no mistake in the expressions he produces in various selects/updates
5- all the above is database related. once it reaches your application, you are free.
you can read the 16 flags from the database and produce your integer and from now on, your code can use bit manipulation on it and you can save time (by writing your functions that deal with it once and using them). I personally think that here too its better not to do so but anyway its your choice.
I know i am not focused and that i might have repeated here and there. But I also hope that i was able to help you in seeing longer term considerations that will help you make the right choice for your case.
take a look at SET Column Type
You can use EnumSet. It's the best way to emulate flags - much more clear in design and have almost the same performance as int. Can be easily translated to int (to read/put into database). For more information look at "Effective Java" book, chapter "EnumSet"
In the primary question you ask that what is more efficient then what is better. This complicate the answer.
From point of view of Developer and DBA having a single column is more efficient solution. Because you spare place and using masks you increase the performance of inserts and updates.
From point of view data analyst the separate column is more efficient solution, each column has specified role.
As goes fro me i prefer the masks
- Les changes in code
- Better management (limited integer capacity is a risk here)