This question is a bit hard to explain in pure text so I've made two gifs.
I would like Atom to behave like this when writing code. Imagine you have a block of code and realize you need to wrap it in a function, if-statement or some other sort of {}-ish thing.
When writing in WebStorm it automatically indents the correct way IMO, so I would like to achieve this same behaviour in Atom.
So this is WebStorm (the way I like)
And this is the Atom version (the way I dislike)
Related
Is there any reason why the expression
(foo5 (foo4 (foo3 (foo2 (foo1 arg)))))
cannot be replaced with
(foo5 (foo4 (foo3 (foo2 (foo1 arg)-)
or the like, and then expanded back?
I know lack of reader macros means that you cannot change syntax, but can this expansion possibly be hard coded into the java?
I do this when I hand write code.
Yes, you could do this, even without reader macros (in fact, you can change Clojures syntax with a bit of hacking).
But, the question is, what would it gain you? Would it always expand to top-level? But then cutting and pasting code would fail, if you moved it to or from top level. And, of course, all the various tools that operate of clojure syntax would need to understand it.
Ultimately if you really dislike all the close parens why not use
(-> arg foo1 foo2 foo3 foo4)
instead?
Yes, this could be done, but I'm not sure it is the right solution and there are a number of negatives which will likely outweigh the benefits.
Suggestions like this are often the result of poor coding tools and a 'traditional' conceptual model for writing code. Selecting the right tools and looking at your code from a slightly different perspective will usually eliminate the cause which lead to this type of suggestion.
Most of the non-functional, non-lispy style languages are based around a token and line model of code. You tend to think of the code in terms of lines of tokens and you tend to edit the code on this basis. There is typically less nesting of expressions and lines are usually terminated with some marker, such as a semi-colan. Likewise, tools such as your editor, have features which have evolved to support token and line based editing. They are good at it.
The lisp style languages are less focused on lines of tokens. The emphasis here is on list forms. lines of tokens are replaced with nested lists of symbols - the line is less relevant and you typically have a lot more nesting of forms. This change means your standard line oriented tools, like your editor, are less suitable. The typical mental model of the code as lines of tokens is also less useful.
With languages like Clojure, your better off thinking in terms of list forms and not lines of code. Once you make this transition, you then start looking for tools which also model the code along these lines. For example, you either look for editors specifically designed to work with lists of data rather than lines of data or you look for editors which have extensions which will allow you to work with lists.
Once your editor understands that lists are the fundamental grouping unit, not lines, things like parenthesis become largely irrelevant from a code writing/editing perspective. You don't worry about closing parenthesis, counting parenthesis nesting levels etc. This all gets managed by the editor automatically. You don't move by lines, you move by lists, you don't kill/delete a line, you kill a list, you don't cut and copy a block of lines, you cut and copy a list of lists etc.
The good news is that in many respects, the structure of these list based code representations are actually easier to manipulate than most of the line based languages. This is primarily because there is less ambiguity or complexity. There are fewer exceptions to the rules and the rules are inherently simple. As a consequence, many editors designed for programmers will have support for this style of coding as well as advanced features which are difficult to implement in less structured code.
My suspicion is that your suggestion to have an additional bit of syntactic sugar to avoid having to type multiple closing parenthesis is actually a symptom of not having the right tools to write your code. Once you do, you will almost never need to enter a closing parenthesis or count opening parens to ensure you get the nesting right. This will be handled by the editor. Your biggest challenge will be in shifting your mental model to think in terms of lists and lists of lists. The parens will become largely invisible and you will jump around in your code according to list units rather than line units. The change is not easy and it can take some time to re-train your brain and fingers, but once you do, you will likely be surprised at how quickly you begin to edit and manipulate your code.
If your an emacs user, I highly recommend extensions such as paredit and lispy. If your using some other editor, look for paredit type extensions. However, as these are extensions, you must also spend some time training yourself to use whatever the key bindings are that the extension uses - there is no point having an extension with great code navigaiton based on lists if you still just arrow around with the arrow keys (unless it is emacs and you have re-bound those arrow keys to use the paredit navigation bindings).
I am learning how to use Emacs to write code (c++). I was wondering, if there a package (I am using Emacs 24.3) that can highlight syntax elements which are pair or belong to the same group? For example, I would like three elements if, elseif, else to be highlighted at the same time when the cursor is on any of them, so that I can see clearly which three blocks of code belong to the same condition sentence. I think it is useful especially when there is nesting if sentences. Another scenario would be (I am not sure if it is the same feature as previous one), when the cursor is on a return key word, all return keywords will be highlighted at the same time. That way I can check all the exiting cases in a function.
BTW this feature might be less useful in c++ than in some other languages such as shell scripting or VB.NET, where there is no curly bracket. But it is still a good helper in reading the code.
I don't think there's such a thing already for C++. For languages whose major modes uses SMIE for navigation and indentation (e.g. ruby-mode), you can enable show-paren-mode which will highlight the matching opening/closing keyword. If you're on the "if" it won't highlight the else/elseif, tho.
And I don't know any package which higlights all the "return"s in a function, although this should be fairly easy to write based on beginning-of-defun and end-of-defun.
I'm using CounterClockWise to develop my first Clojure project on the Windows 7 OS. Besides javascript (which I'm not too familiar with), this is my first dynamically typed language.
The hardest part of building my project was debugging the issues I had. The technique I've been using is to sprinkle printlns in places to confirm my inputs and outputs are what I want them to be.
Compared to Java, it seems that a lot of Clojure functions accept what I'd consider garbage input and happily return nil. As a result, the runtime exception you see can come from many functions away from the cause of the problem. My point being, it can be hard to even know where to put the printlns.
And, these runtime exceptions were outputing compiled code line numbers so they weren't very informative. Most of my functions were short and side-effect free but the problem is my inputs were webpages. Sometimes the input to a function was the raw html, sometimes it was the parsed html (by enlive), sometimes it was a list of links (by using a css-like selector on the parsed html). These inputs could be deeply nested, complex structures (ie: a list of maps of maps of lists of maps) so it wasn't easy to build them up by hand. When you've got a stack trace that's not pointing to the issue, I'd pretty much have to debug half my program and figure out how to generate inputs to each part. It was pretty time consuming.
On the IRC channel someone informed me of the stacktrace library which made debugging that much easier. It still pointed many functions away from the source of the bad input, but it was still helpful. I'm looking for more techniques like this. What are some techniques I can use to debug my code better?
Since most functions in Clojure should be rather short (or decomposed to be short) and usually work without side affects, you can always try them separately from Clojure REPL or write tests for them.
Also you can use Java debugger/breakpoints with La Clojure plugin for IntelliJ IDEA - see my answer to: How to run/debug compojure web app via counterclockwise (or la clojure) for more details on using IDEA to run & debug Clojure projects.
If garbage input/unexpected output is an issue for you when calling other functions, maybe you could restructure your code a bit so that these touch points are encapsulated in their own functions with pre/post conditions defined. e.g. http://blog.fogus.me/2009/12/21/clojures-pre-and-post/
I'm sure you could make it much more of a pleasing thing to code with a little bit of macro support. Although that might make the stack traces harder to read.
This is a followup to Clojure: pre post functions
Goal
For every Clojure function, I want to have a pre and post function that gets executed:
right before the function is evaluated and
right after the function returns
Now, I want to do this all functions in my *.clj files.
I would prefer (this is also an learning exercise) to do this at the Clojure Compiler level.
Question:
How do I get started on this? What part of the Clojure Compiler source code should I be reading? What documentation / tutorials on the internals of the Clojure Compiler I should be aware of?
Thanks!
First off, this sounds like a slightly crazy thing to do in general. There are almost certainly better ways to achieve any sensible objective (i.e. this is screaming "XY Problem"). But as long as you say it is just for a learning exercise, that is fine :-)
I can think of a couple of strategies you might want to consider before hacking the compiler:
Create your own defn macro that does the wrapping when functions are created. Obviously you'll need to make sure your own version of defn is used rather than the built-in one. Probably the simplest solution.
Walk your namespaces at runtime (after they are loaded) and redefine all functions to a wrapped version of the same function. Could get a bit messy but will certainly enhance your understanding of namespaces :-)
If you really want to hack the compiler, the easiest place to make this change would probably be just by hacking defn in core.clj
Let’s say that you decide to change the name of Stack Overflow to Frack Overflow.
Now, in your code you already have dozens of objects and variables and selectors with some variation of the name "Stack". You want them to now be replaced with "Frack".
So my question is, would you opt to run your entire codebase through a regular expression filter and change all of these names? Or would you let them be?
I would use the "rename" feature of a good IDE to do it for me.
It depends, really.
In a language like C++, you can get away with this because the compiler will let you know right away if something would break. However, other less-picky languages will allow you to refer to variables which don't exist, and the worst that happens is a slap on the wrist in the form of an exception being thrown for a null reference.
I was working on a flex project once where the codebase was a real mess, and we decided to go through the code and beautify it a bit to meet the Adobe AS3 coding standards. Since I was new to the project, I didn't realize that the variable names in some classes actually referred to persistent objects which hibernate (running the java webapp for the backend server) was using to create mappings. So renaming these variables caused the entire flex frontend to misbehave, even when we did it with the "correct" refactoring tools in our IDE.
But really, I'd say to check your OCD at the door and make your changes a little at a time. Any time you change dozens of files in a large project, you risk destabilizing it, and in this case, the benefit derived from such a risk doesn't pay off.
I'd first ask myself the question why? It is a risk/reward judgement at the end of the day which only you can make.
I would be very reluctant to do it for stylistic reasons, but for class re-factoring it may be legitimate.
Well, not necessarily a disaster, but it certainly can cause some trouble on large code bases. That's why I hate hungarian notation: it makes you change all of your variable names if you happen to change its type.
If there are objects, members and fields in your solution with names that reference a certain customer implementation, I would work hard to re-factor these to use more generic names instead, and I would let Resharper do the re-naming, not some generic text-search-and-replace tool.
Just use a refactoring tool like Resharper by JetBrains or CodeRush and Refactor! by DevExpress. They change all references of a variable in your entire codebase automatically and can do much more.
I believe Refactor! is even included in the VB version of Visual Studio. I use Resharper and I refuse to develop without it.
If I were using a source code version control system (like svn, git, bazar, mercurial etc) I would not be afraid to refactor my code.
Use some kind of "find replace all" or refactoring of some IDE, compile (if it is not a dynamic language) and run your tests (if any).
If something goes horribly wrong, you can always revert your code using the source control system.
Renaming is perhaps the most common refactoring. It is rather encouraged to refactor your code as you go, as this gives you the flexibility of not having to make permanent decisions about names, code placement, etc. as you are first writing your application. If you are not familiar with the idea, I would suggest you start with the Wikipedia page and then dive into Martin Fowler's site.
However, if you need to write your own regex to rename things, then imho you could use some better tools. Don't waste your time reinventing the wheel -- and then fixing whatever your new wheel broke by accident. If you have the option, use an existing tool (IDE or whatever) to do the dirty work.
Even if you have "dozens" of things to rename, I think you're better off finding them one by one manually, and then using an automatic Rename to fix all instances throughout your code.
You need good justification for doing it, I think. When I make changes that have a large number of potential side effects across a large codebase, which happens from time to time, I usually look for a way to make the compiler fail on spots I've missed. And, if possible, I tend to do it in stages so as to minimize the break.
I wouldn't rename just for the sake of renaming, though.