Vimscript is difficult. Ruby is not quite so diffiuclt. Customizing Vim with Ruby scripts can be done, and I am trying to learn how. This is a useful presentation about it which covers the basics, but meaningful examples are scarce (and these are rather complicated), so I'm wondering if anyone with experience in this area can offer some smaller examples of Vim mappings and shortcuts written in Ruby.
As a specific example of the kind of scale I'm looking for, let's suppose I want to create section headers for my documentation or something, as in
----------------------------------------------
------------------- SECTION ------------------
----------------------------------------------
where the section name is centered in the set of hyphens, and to achieve this I visually select the word
SECTION
on it's own line, and hit leader <arbitrary keystroke>.
Counterargument: Vimscript isn't difficult, maybe a bit different; after all, much of it is modeled after Python.
I do agree that for certain, complex tasks (especially anything that requires interaction with the "outside world", be it file systems, web service calls, etc.), or stuff that benefits from library functions, a different programming language (and fortunately one can choose among powerhorses like Perl, Python, and Ruby) has undeniable benefits.
But the example task you're giving is just a simple sequence of yanking, simple string manipulation, followed by paste. There's little meat, and the interaction with the Vim buffer isn't that different when done in an integration language. That's my main point: You still have to integrate with Vim, and for that, some knowledge of Vim's structure (and that means Vimscript) is necessary.
Related
I'm in the process of translating a Open Source project from Chinese to English, and I've used i18n (in this case babel) to separate the code from both English and Chinese translations.
Everything's done, except for a rather large number of inline comments in the code.
Obviously, babel can't translate comments inline (and it would be rather obnoxious if it did, anyway. Since code would not be unique across languages and therefore less easily verifiable.)
The way I see it, there are a number of options:
Leave comments in -
Pro: Helps original author, etc.
Con: Makes it distracting for ongoing translation and anyone who doesn't speak the language
Strip out all the comments -
Pro: Code is native-language-agnostic, so it makes sense. Who needs comments anyway? Use the source, Luke!
Con: Goes against SE principles. Could lose something important in understanding how the code works - maybe something's been done to avoid a security risk, etc.
Place English comments near Chinese comments
(Possibly moved to lines above and prefixed with "EN" and "ZH", for example).
Pro: Best of both worlds, comments kept close to code
Con: Not conducive to dictionary-style translation. Can get bulky with more languages.
Create a comment dictionary / notes
Pro: Keeps the comments in a separate file for easy translation.
Con: Difficult to keep synced with code. Not intuitive to remember to update comments related to code when changing coe.
Use a different preprocessor for i18n before/after each development cycle.
Pro: Comments et al would be in your language. Could link this to git pull/push so you only ever see the code in your language.
Con: Bulky, non-obvious process. Could result in code-verification or even compilation errors.
None of these seem like really great solutions.
If you do alot of this, and the code is shared publicly between developers who don't share a native tongue, is there a recommended way to handle translating (or not) comments in the code itself?
I am not sure I understand... You say you separated the code from the languages part. So now you should have code (with comments) + English resources + Chinese resources (i used resources for whatever your programming language use to store localizable content)
Translators only see the resources, not the code, nor the comments. The comments stay untranslated, for the developers.
Short Answer
It seems to be a mixture of:
Strip out all the comments, and
Place English comments near Chinese comments.
Inline comments are almost always trivial - Strip them
Functional comments are not as intrusive - Translate them (possibly with a i18n prefix e.g. "[cn]:" or "[en]:").
Explanation
My meagre amount of research tends to suggest that larger projects make strong attempts to reduce comments and let the code explain itself, instead focusing on code quality which reduces the need for comments.
e.g. From the Linux Kernel Coding guidelines:
NEVER try to explain HOW your code works in a comment: it's much
better to write the code so that the working is obvious, and it's
a waste of time to explain badly written code.
...and from the MySQL coding standards:
Comment your code when you do something that someone else may think is
not trivial.
Both of these standards (and others) recommend minimal function descriptions also, so that's not as obtrusive to understanding the code, and, since function descriptions are generally multi-lined and above the code itself, multiple languages can be included as necessary.
Maybe someone, somewhere has built an interface that can isolate comments into the readers language, but I couldn't (yet) find any that do so.
I always think that API comments exported in the project and private comments in open source projects should be internationalized, which is very convenient for developers in other countries.
On Github, there are actually many developers who use their own national language to comment on some well-known open source projects and some of their own annotations. Most of the reason is that if they do not translate, the efficiency of developers reading comments very low.
Similar to .d.ts in TypeScript, I think function annotation translation can also take a similar form, which is more convenient for the community to feedback translation content, because in fact many developers are willing to do so.
Maybe this question is too open-ended and someone will kill it
--- however:
I am building systems (web apps and native) requiring multiple language support, including rtl languages like Arabic and Hebrew. Currently I have no need to be able to program in those languages, but writing content is a must.
There are some difficult choices to make I think in the implementation, because I think at some level (I don't know it's why I'm asking) the text file needs to have a consistent direction of string flow, but when we read and compose these files we need to view these elements with their character order reversed in order for them to be sensible.
(Open ended and non-constructive? I'm hoping to construct a solution.)
I fail to see the connection with SublimeText.
You need RTL support, you use a pre-made component that can handle it.
Or start with a library that can help with that support and does the heavy-lifting (for instance Uniscribe, http://msdn.microsoft.com/en-us/library/windows/desktop/dd374091%28v=vs.85%29.aspx,
or HarfBuzz, http://www.freedesktop.org/wiki/Software/HarfBuzz/)
Adding it yourself means a lot of work (SublimeText fails miserably at it, I don't even think it tries).
To get an idea what you have to deal with, take a look at the Unicode Bidirectional Algorithm
(http://www.unicode.org/reports/tr9/)
Just vote for adding RTL Languages here...
https://sublimetext.userecho.com/topic/37207-right-to-left-languages-support/
They will add it if the votes reach 600
So iOS 6 deprecates presentModalViewController:animated: and dismissModalViewControllerAnimated:, and it replaces them with presentViewController:animated:completion: and dismissViewControllerAnimated:completion:, respectively. I suppose I could use find-replace to update my app, although it would be awkward with the present* methods, since the controller to be presented is different every time. I know I could handle that situation with a regex, but I don't feel comfortable enough with regex to try using it with my 1000+-files-big app.
So I'm wondering: Does Xcode have some magic "update deprecated methods" command or something? I mean, I've described my particular situation above, but in general, deprecations come around with every OS release. Is there a better way to update an app than simply to use find-replace?
You might be interested in Program Transformation Systems.
These are tools that can automatically modify source code, using pattern-directed source-to-source transformations ("if you see this source-level pattern, replace it by that source-level pattern") that operate on code structures rather than text. Done properly, these transformations can be reliable and semantically correct, and they're a lot easier to write than low-level procedural code that navigates and smashes nanoscopic actual tree structures.
It is not the case that using such tools is easy; such tools have to know how to parse the language of interest into compiler data structures, (e.g., ObjectiveC), process the patterns, and regenerate compilable source code from the modified structures. Even with the basic transformation engine, somebody needs to carefully define parsers (and unparsers!) for the dialects of the languages of interest. And it takes time to learn how to use such a even if you have such parsers/unparsers. This is worth it if the changes you need to make are "regular" (in the program transformation sense, not the regexp sense) and widespread (as yours seem to be).
Our DMS Software Reengineering toolkit has an ObjectiveC front end, and can carry out such transformations.
no there is no magic like that
I'm writing a small program in Ruby to parse a hand history log from a poker site.
The log is split over several lines and looks a bit like this:
Table 123456 NL Hold'em $1/$2
5 Players
Seat 3 is the button
Seat 1: randomGuy112 $152.56
Seat 2: randomGirl99 $200
Seat 3: PokerPro $357.12
Seat 4: FishCake556 $57.19
Seat 6: MooMoo $188.98
Dealt to MooMoo [Ah, Ks]
randomGuy112 folds
randomGirl99 raises to $7
etc.. etc..
I want to summarise this information in an object which then might, for example,
render it differently or save it to database.
When I originally thought of this problem I thought I'd just have one realativly straight forward class with a number of regexes and several if/else statements. I then realised this could turn into quite a large method and potentially be a nightmare to debug/maintain. Keep in mind it needs to loop at each stage of the game (preflop,flop etc) to collect player's actions.
I also want to tackle this with a TDD approach, but the 'one long method' way means that the tests for with checking later input will kind of rely on earlier tests.
I'm quite new to Ruby and havn't yet clicked on the 'Ruby way' to do things. I'm catching myself writing C# code
in a different language.
Can you give me some pointers on how to design the parser so it isn't one huge mess of if/else statements and more testable?
Use Treetop
It does look like you are on the borderline between what ad hoc string matching and RE's are good for, and what requires an actual parser.
There is nothing wrong with handwritten parsers, and as long as you keep your methods short, without a lot of complexity in any given one, it's OK to have as many if statements in total as the parser requires.
I'm not sure 10 lines with incomprehensible regular expressions is any better than 30 lines of nice looking code.
Now, Ruby does have an advanced PEG parser generator. I think in this case I wouldn't worry about whether it was overkill, I would just go ahead and use Treetop.
State Machine, anyone?
At any point in the play of a poker hand there is a clearly-defined set of possible next actions. I'd think you could encapsulate them into a state machine. There are a few around, amongst which (no recommendations, I'm afraid - not enough experience with any) are
Alter Ego (updated July this year)
ruby-state-machine (seems also to be alive)
statemachine (looks a bit stale)
You can checkout this open source poker game hand parser
It looks like they created a hash of regular expressions and then they probably iterate over the regex data structures. It is a more simple machine than a parser and probably a more light weight approach.
I wrote hand history parser for PokerStars log files https://github.com/malikbakt/pokerstars
You may want to look at: StringScanner.
I have two different pointers for you, which will point you to the solution, on how to write code in the ruby way.
Get a ruby book. The ruby book will have a lot of examples on how to write code in the ruby way. From my personal expirience I can recommend you the pixake(is this spelled right?) book: http://www.ruby-doc.org/docs/ProgrammingRuby/html/index.html
Read existing ruby code. You seem to know enough ruby to write code? Then you should certainly be able to read existing code. I assume you already have installed ruby on your system. If so, you will find plenty of sourcecode on your harddrive. If not just use the internet.
I'd recommend the book Refactoring by Martin Fowler (available in both dead-tree and electronic formats, IIRC). He covers object-oriented remedies for exactly the design problems you're asking about, all in a test-driven context. This is one of those books that everyone in the profession should read.
I am writing a coding standards document for a team of about 15 developers with a project load of between 10 and 15 projects a year. Amongst other sections (which I may post here as I get to them) I am writing a section on code formatting. So to start with, I think it is wise that, for whatever reason, we establish some basic, consistent code formatting/naming standards.
I've looked at roughly 10 projects written over the last 3 years from this team and I'm, obviously, finding a pretty wide range of styles. Contractors come in and out and at times, and sometimes even double the team size.
I am looking for a few suggestions for code formatting and naming standards that have really paid off ... but that can also really be justified. I think consistency and shared-patterns go a long way to making the code more maintainable ... but, are there other things I ought to consider when defining said standards?
How do you lineup parenthesis? Do you follow the same parenthesis guidelines when dealing with classes, methods, try catch blocks, switch statements, if else blocks, etc.
Do you line up fields on a column? Do you notate/prefix private variables with an underscore? Do you follow any naming conventions to make it easier to find particulars in a file? How do you order the members of your class?
What about suggestions for namespaces, packaging or source code folder/organization standards? I tend to start with something like:
<com|org|...>.<company>.<app>.<layer>.<function>.ClassName
I'm curious to see if there are other, more accepted, practices than what I am accustomed to -- before I venture off dictating these standards. Links to standards already published online would be great too -- even though I've done a bit of that already.
First find a automated code-formatter that works with your language. Reason: Whatever the document says, people will inevitably break the rules. It's much easier to run code through a formatter than to nit-pick in a code review.
If you're using a language with an existing standard (e.g. Java, C#), it's easiest to use it, or at least start with it as a first draft. Sun put a lot of thought into their formatting rules; you might as well take advantage of it.
In any case, remember that much research has shown that varying things like brace position and whitespace use has no measurable effect on productivity or understandability or prevalence of bugs. Just having any standard is the key.
Coming from the automotive industry, here's a few style standards used for concrete reasons:
Always used braces in control structures, and place them on separate lines. This eliminates problems with people adding code and including it or not including it mistakenly inside a control structure.
if(...)
{
}
All switches/selects have a default case. The default case logs an error if it's not a valid path.
For the same reason as above, any if...elseif... control structures MUST end with a default else that also logs an error if it's not a valid path. A single if statement does not require this.
In the occasional case where a loop or control structure is intentionally empty, a semicolon is always placed within to indicate that this is intentional.
while(stillwaiting())
{
;
}
Naming standards have very different styles for typedefs, defined constants, module global variables, etc. Variable names include type. You can look at the name and have a good idea of what module it pertains to, its scope, and type. This makes it easy to detect errors related to types, etc.
There are others, but these are the top off my head.
-Adam
I'm going to second Jason's suggestion.
I just completed a standards document for a team of 10-12 that work mostly in perl. The document says to use "perltidy-like indentation for complex data structures." We also provided everyone with example perltidy settings that would clean up their code to meet this standard. It was very clear and very much industry-standard for the language so we had great buyoff on it by the team.
When setting out to write this document, I asked around for some examples of great code in our repository and googled a bit to find other standards documents that smarter architects than I to construct a template. It was tough being concise and pragmatic without crossing into micro-manager territory but very much worth it; having any standard is indeed key.
Hope it works out!
It obviously varies depending on languages and technologies. By the look of your example name space I am going to guess java, in which case http://java.sun.com/docs/codeconv/ is a really good place to start. You might also want to look at something like maven's standard directory structure which will make all your projects look similar.