I'm wondering whats the point of this, first I think it's not a good idea to use space for indentation (somehow Android Studio think it does), second even if I tell it to use tabs it always starts with two tabs on new line, instead of one, turning this:
getSupportFragmentManager().beginTransaction().commit();
into this:
getSupportFragmentManager()
.beginTransaction()
.commit();
Why the two tabs? I know you can set it as "Continuation Indent" to one tab or whatever you want, but cant really understand this, is there anyone who uses two tabs instead of one? What is the thought behind it? Why two tabs by default?
I can only assume it's so that the continuation method calls are somewhat closer to the first method in the chain, for readability. Variable/field/method names are generally more than 8 characters long; they are rarely around 4 characters. When writing using a builder pattern, you generally put the first method on the first line and then subsequent methods should be roughly underneath.
E.g. this:
foobarbaz.builder()
.foo()
.bar()
.baz()
.build();
Rather than this:
foobarbaz.builder()
.foo()
.bar()
.baz()
.build();
In this case, it's more obvious that the methods are stacked on top of each other in the first case.
Obviously the readability depends on the length of the method/variable name on the first line. But I think JetBrains just tried to guess the typical length and set the continuation indent accordingly.
Related
It seems like it's simply more straightforward to hard-code the text values. In an event that these values should be changed it seems like it would be more logical to search for the relevant UI element in each activity's xml layout file rather than look through the entire strings.xml. Of course if you have certain UI elements across multiple activities that all share the same text then this might be an exception (like a back button for instance), but generally there doesn't seem to be much advantage to storing these in the strings.xml. Am I missing something?
I will give you two reasons;
1 - Avoid duplication: all of your strings in one place. also, you can use string value many times. when you want to change it, there is one place to do the change. that makes it easier to maintain.
2 - Multi-language support: if you want to translate your strings to another language you must have all the strings in Strings.xml
let me know if you need more clarifications.
I have the awesome vim-sexp and vim-sexp-mappings-for-regular-people plugins installed, and I've come across a situation I'm not sure how to solve.
Suppose I have the following form:
(alimony barbara (code determinant) eclair final-countdown)
How can I transform that to:
(alimony
barbara
(code determinant)
eclair
final-countdown)
I can go ahead and insert a newline before every inner-form/element, but that is a bit tedious. There should be a way with or without the sexp plugin
This is an old question, but maybe an updated answer will help someone who comes here in the future.
You don't have to write the program mentioned by Kaz. Others have already done it. I have not tried them, but here are a few:
fipp,
cljfmt,
cljstyle,
zprint,
joker. (The last one does more than code formatting.)
As Kaz suggests, once installed, you can pipe code to a formatter using !. You can even bind this operation to a key combination. Some of the formatters offer suggestions about how to do this sort of thing.
In addition, some vim IDE plugins, such as vim-iced provide support for using an external formatter.
A productive way to get this behavior would be, rather than fighting with Vim modules and extensions, to write a Lisp program which reads S-expressions and outputs them reformatted in the desired way. To use that program out of Vim, just pipe a range of lines into it using the ! command.
I took a look at this, and I thought it was a color scheme or something. I followed my stems to find out that it's not.
What are "Code Styles" and what changes can they, for example, do?
Code styles dictate what happens when you auto-format your code, which includes:
The placing of braces, forcing or omitting their inclusion with a single statement
The amount of spaces indentation does
Whether or not you chop down or wrap long statements or parameters
How annotations appear in fields (on top of/next to)
Whether or not you use import * statements in Java, and what/when the cutoff is
How you close ML tags (XML, HTML, etc - either with the </full-name> or <full-name />)
...and many other pieces.
Code style varies from person to person, and shop to shop, so having IntelliJ as a way to configure this once and shared with others is ideal.
According to Oracle at JTextArea documentation, if you wish to wrap lines AND wrap at word boundaries and not character boundaries you must use code as follows:
jtaOutputPrimes.setLineWrap(true);
jtaOutputPrimes.setWrapStyleWord(true);
Please note that the jtaOutputPrimes is the name of my JTextArea on my JPanel.
The issue comes in when I use the method append to add text to the JTextArea as follows:
jtaOutputPrimes.append(",");
In this case, the setWrapStyleWord setting does not work. It continues to use the character boundaries and not the word boundaries.
I have found another person experiencing same issue here: setWrapStyleWord issue
Now, lets say you are running an JApplet that has this JTextArea. If you type in the text area, it will word wrap fine, but any passed text from the append method does not work.
I believe this is a bug, and I cannot find Oracle acknowledge it as such anywhere.
Can anyone help? Thanks!
I found out why this was happening, and this simple fix may be beneficial to others. The issue came into play because when I appended the comma (,) to the JTextArea it was eliminating the white space between words. To fix this, I simply placed a space after the comma like so, and it worked.
jtaOutputPrimes.append(", ");
If you work with ColdFusion, you've probably gotten used to either line-wrapping or horizontal scrolling. Infrequently, this isn't so bad, but when three out of four lines in an existing code base are wrapped, sometimes twice, it becomes a huge readability hindrance.
A line such as...
<cffunction name="v_multiple_item" access="public" output="false" returntype="query">
can easily be broken up HTML-like into
<cffunction name = "v_multiple_item"
access = "public"
output = "false"
returntype = "query"
>
Which is fairly easy to automate with a macro in a good editor. What I'm more concerned with is interspersed ColdFusion and HTML, like so:
<cffunction..>
<cfif..>
<cfif..>
<form..>
<div..>
<table..>
<tr..>
<td..>
<cfif..>
<select..>
<cfoutput>
<option>#stuff#</option>
</cfoutput>
It's not uncommon that I see lines of code, with 8-sp tabs, that are line-wrapped during the whitespace.
Reducing tab width hasn't been enough. The code base is too big for rewrites/frameworkification to be an option. Left-justify everything?
Is there a simple, winning strategy for reducing line widths to a manageable level without further damaging readability?
I don't want to get into a 'tabs versus spaces' issue here, but one thing you can do is adjust your tabs in the IDE. If you use tabbing, you could always make a tab be 2 or 3 spaces rather than 8 (or more). This will reduce the unnecessary whitespace, at least visually.
In Eclipse you can do this under Preferences > General > Editors > Text Editors. There's a 'Displayed Tab Width' there which you can reduce to your heart's content.
The real answer, however, is that this is just the nature of the beast. If you're going to intermix CF with HTML, and you want clarity, you'll indent your code.
Edit: Come to think of it, CFInclude just came to mind. Granted, this can also cause spaghetti code, but how things like this are often handled is with CFInclude. You can break reusable portions of CF code into cfm templates and include those. For a situation with a header, with many nested divs and pieces of CF logic intermixed, you'd be better off using a cfinclude anyway. So an index.cfm page that looked like your example might instead look more like this:
<cfinclude template="header.cfm">
<div>Some Content Here</div>
<cfinclude template="footer.cfm">
All of your wrapping is included in header.cfm or footer.cfm. You can even do includes within those templates as well, keeping things like the navigation isolated into a separate cfm page as well.
I'm not advocating that you go hogwild with includes, but it's a standard way of handling reuseable snippets of HTML/CFML in ColdFusion, and breaks things up into conceptual blocks that makes it easier to find what you're looking for.
IMO, this isn't a ColdFusion specific problem, this is related to code readability in general.
My solution? I got a 28" monitor. :)