When working on different projects, with different people and using different frameworks you often struggle to keep your code compliant to their conventions. Some teams get very strict about naming variables/methods/classes and other things the others make holy wars around the topic. I understand them and I fully support, but as any developer I have my own preference I wish I could code with comfortably. This makes me think whether there is a simple solution.
Are there any tools or editors that can automatically convert code to follow a different standard? I imagine there can be no such smart tool that will support naming conversions, so I'm ok with that, but I really wish to see
foreach($lala as $lalala) {
and not
foreach($lala as $lalala)
{
same goes with statements:
if(I_LIEK_COOKIES) {
eat_cookie();
} else {
toss_cookie();
}
and not
if ( I_LIEK_COOKIES ) {
eat_cookie();
}
else
{
toss_cookie();
}
(note the spaces between and around the parenthesis too)
I won't even mention spaces/tabs, I can convert it in my IDE with a shortcut but it would be awesome.
So the things I would like to get customized are
spaces between parenthesis
tabs/spaces and spaces per tab
mustache brackets on the end of the line or on the new line
always attach mustache brackets to any if/ifelse/else/for/foreach etc.
Some of the extras anyone would appreciate:
Line ending style
Delete extra spaces on the line endings (like sublime text 2 can do on save, but would be great for other IDE/editors)
The perfect workflow would be like this:
I pull from git
The code gets converted to my style
I code stuff
I commit and push
Before everything gets pushed(or even commited) code gets converted to the convention style
Of course, someone may wish not to use git, then it would be simply converted when opening and after saving the file but as I understand it's impossible to do outside of an IDE/editor with a tool of some kind.
Has someone stumbled upon something like that? Could not find anything anywhere but tab/space conversion.
P.S. I wish to mention I'm working with PHP/JS so it's prioritized but I code using other languages on my spare time.
You could store configurations (e.g. vim .vimrcs, Eclipse preferences etc.) in each project's version control repository.
However, I think there's a big problem wrt. converting code when pushing/pulling to/from repositories. If someone reports an issue with your code (e.g. exception at line 100), converting the code when pulling from your repository is going to give you a different line 100. I don't think you can practically operate without working on the exact code that your compatriots are working with.
Related
I'm trying to write some markdown text in Visual Studio Code and whenever I write this:
*some text*
It's being replaced by this as soon as I save the file:
_some text_
I narrowed it down to be caused by the Prettier extension. I tried looking for a setting that might control this but didn't find any - well none that was obvious to relate to the issue.
I'd really like to keep Prettier enabled for markdown files as it also keeps tables nice and tidy.
Is there a way around this one issue?
UPDATE:
I am aware that both asterisk and underscore works for italic emphasis when the file is shown through a markdown viewer, but when reading the file as pure text, the asterisk feels more natural to me for emphasis and I'd much prefer keep using it if possible.
I also feel the same way, but from what I can tell Prettier simply does not have that option (https://prettier.io/docs/en/options.html)
Prettier is not a kitchen-sink code formatter that attempts to print your code in any way you wish. It is opinionated.
https://prettier.io/docs/en/option-philosophy.html
Given that philosophy, I doubt this will ever change. As for me, I think I'm going to try to just get over it.
I think the only way to avoid this would be to use something different, for example:
https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint
I've noticed what seems to be a very strong convention among IDEs and code-oriented text editors. Almost any time I create a new code file, regardless of the language, IDE, or platform on which I create the file, they almost always have a trailing new line at the end.
For example:
C++ and C# class wizards in Visual Studio always have this new line after the last curly brace.
The nano editor in the Linux terminal does not allow you to remove the last new line.
Git version control makes a specific point to point out files which do not end with a new line.
So, why is this a common practice? I've never had a problem with scripts where I intentionally remove this new line. Does it have significance for legacy purposes?
Thank you for your time.
While you would be hard pressed to find a modern editor or compiler which has issues with unterminated lines, this wasn't always the case. If you need to manipulate your source code programmatically, there are probably still e.g. sed implementations out there which are buggy in this respect.
At a minimum, you should make a conscious decision about which way you want things; if you are authoring, say, a company coding style guideline, it probably makes sense to require or recommend source files to have a final newline, because it helps avoid religious wars and supports the lowest common denominator.
So I have some formatting rule to follow, such as :
Space on each side of operator (*, =, +, %, etc)
No space at the end of a line
No more than 80 chars per line
Is there a way to highlight in red line containing formating error?
The eclipse auto-formating tool is no good because either :
It will change to many line (old code not written by me)
or it won't (only my code)
Because I must follow some "colorfull" guideline :
You must change formating error relative to operators in old code but nothing else
Your code must be correctly formated.
Any ideas?
Thanks
You can select which lines of code you want to format. The Eclipse formatting tool doesn't have to run across the entire file. To do this: select the lines you want to format, then press Ctrl-Shift-F.
You could try using the Eclipse Checkstyle Plugin.
You'll need to configure it with just the rules that you need (the default configuration is very strict, so create a new one with just the rules you care about).
This will highlight all lines with formatting issues. I don't think it's possible to ignore old code using the plugin.
Talk to whoever created that coding guideline. It does not make sense in the long run, because editing code in Eclipse will always apply all current formatting rules (which violates that guideline) or none, if you disable the formatter (which leads to you writing bad code).
If there is really no way around that guideline, then you should split your workflow into 2 phases: Reformat all existing code one time to fulfill that operator guideline. You may use any tool you like, even just a regular expression search and replace might be fine.
After that has been done, configure Eclipse to auto-format only changed lines, but always apply all formattings to each changed line. There is no good reason to not re-format the other 75 characters in an existing line of code, if you already touched 5 characters of it.
What source control products have a "diff" facility that ignores white space, braces, etc., in calculating the difference between checked-in versions? I seem to remember that Clearcase's diff did this but Visual SourceSafe (or at least the version I used) did not.
The reason I ask is probably pretty typical. Four perfectly reasonable developers on a team have four entirely different ways of formatting their code. Upon checking out the code last changed by someone else, each will immediately run some kind of program or editor macro to format things the way they like. They make actual code changes. They check-in their changes. They go on vacation. Two days later that program, which had been running fine for two years, blows up. The developer assigned to the bug does a diff between versions and finds 204 differences, only 3 of which are of any significance, because the diff algorithm is lame.
Yes, you can have coding standards. Most everyone finds them dreadful. A solution where everyone can have their cake and eat it too seems far more preferable.
=========
EDIT: Thanks to everyone for some great suggestions.
What I take away from this is:
(1) A source control system with plug-in type diffs is preferable.
(2) Find a diff with suitable options.
(3) Use a good source formatting program and settle on a check-in standard.
Sounds like a plan. Thanks again.
Git does have these options:
--ignore-space-at-eol
Ignore changes in whitespace at EOL.
-b, --ignore-space-change
Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more
whitespace characters to be equivalent.
-w, --ignore-all-space
Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has
none.
I am not sure if brace changes can be ignored using Git's diff.
If it is C/C++ code, you can define Astyle rules and then convert the source code's brace style to the one that you want, using Astyle. A git diff will then produce sane output.
Choose one (dreadful) coding standard, write it down in some official coding standards document, and get on with your life, messing with whitespace is not productive work.
And remember you are a professional developer, it's your job to get the project done, changing anything in the code because of a personal style preference hurts the project - it wont only make diff-ing more difficult, it can also introduce hard to find problems if your source formatter or compiler has bugs (and your fancy diff tool won't save you when two co-worker start fighting over casing).
And if someone just doesn't agree to work with the selected style just remind him (or her) that he is programming as a profession not as an hobby, see http://www.ericsink.com/entries/No_Great_Hackers.html
Maybe you should choose one format and run some indentation tool before checking in so that each person can check out, reformat to his/her own preferences, do the changes, reformat back to the official standard and then check in?
A couple of extra steps but they already use indentation tools when working. Maybe it can be a triggered check-in script?
Edit: this would perhaps also solve the brace problem.
(I haven't tried this solution myself, hence the "perhapes" and "maybes", but I have been in projects with the same problems, and it is a pain to try to go through diffs with hundreds of irrelevant changes that are not limited to whitespace, but includes the formatting itself.)
As explained in Is it possible for git-merge to ignore line-ending differences?, it is more a matter to associate the right diff tool to your favorite VCS, rather than to rely on the right VCS option (even if Git does have some options regarding whitespace, like the one mentioned in Alan's answer, it will always be not as complete as one would like).
DiffMerge is the more complete on those "ignore" options, as it can not only ignore spaces but also other "variations" based on the programming language used in a given file.
Subversion apparently supports this, either natively in the latest versions, or by using an alternate diff like Gnu Diff.
Beyond Compare does this (and much much more) and you can integrate it either in Subversion or Sourcesafe as an external diff tool.
I'm wondering if the need to alter the indentation of code to adjust the nesting has any adverse effects on merging changes in a system like SVN.
I've used python with SVN and Mercurial, and have no hassles merging.
It all depends on how the diffing is done - and I suspect that it is character-by-character, which would notice the difference between one level of indent and another.
It works fine so long as everyone on the project has agreed to use the same whitespace style (spaces or tabs).
But I've seen cases where a developer has converted an entire file from spaces to tabs (I think Eclipse had that as a feature, bound to Ctrl+Tab!), which makes spotting diffs near impossible.
Generally source control systems merge on a line-by-line basis by default. I have found that merging Python code is no different from merging any other source code that is reasonably indented. If one programmer wraps a block of code in an if statement (indenting the whole block), and another programmer modifies something inside the block, then there will be a merge conflict. Fortunately, the conflict in this case is super easy to resolve.
If you use an external merge tool, then your tool may support more detailed textual merging algorithms that take the above scenario into account automatically.