vim to generate code template dynamically - vim

I have to write test cases which contains repetive code.
The name of the method should be the ClassName delimitted with _ ex: class_name_test
The object name should be classNameObj and the mock method should take ClassName.class
The genericObj.call statement is common for all methods
The sayHello should be bound to classNameObj and the remaining result is common
The commonMethods is common for all objects
Instead of copy pasting and changing the ClassName and classNameObj, I am interested in automating this using Vim. Is is possible to do this to which if I pass the Class name, the rest should be generated?
The method template is mentioned below.
#Test
public void stop_video_request_valid_data() throws Throwable {
ClassName classNameObj = mock(ClassName.class);
when(genericObj.call()).thenReturn(new Object[]{classNameObj});
when(classNameObj.sayHello()).thenReturn("Hello");
commonMethods();
}

snippets are like the built-in :abbreviate on steroids, usually with parameter insertions, mirroring, and multiple stops inside them. One of the first, very famous (and still widely used) Vim plugins is snipMate (inspired by the TextMate editor); unfortunately, it's not maintained any more; though there is a fork. A modern alternative (that requires Python though) is UltiSnips. There are more, see this list on the Vim Tips Wiki.
There are three things to evaluate: First, the features of the snippet engine itself, second, the quality and breadth of snippets provided by the author or others; third, how easy it is to add new snippets.

Related

Vim generate function definition from the declaration

I'm learning to use vim, but I think it's inconvenient to generate function definition in .cpp file from its declaration in .h file.
For example, if I declare a function void print(const vector<int>& arr); in A.h, I have to open A.cpp and type the following:
void print(const vector<int>& arr) {
}
(or use yy copy the declaration line, then delete ; and add {}...)
When some derived classes need to override function in base class, it can be a heavy job...
Is there any convenient plugin or command to help me deal with it?
My lh-cpp plugin has been providing this feature for quite some time now.
Go on the function declaration, type :GOTOIMPL et voilà!. It either moves the cursor to a function definition (from its declaration), or if none exists, it generates an empty shell to define that function.
Note: I'm currently in the process of improving the feature to support any kind of function declaration. To support template functions, you'd have to use the gotoimpl_with_libclang branch and the support plugin vim-clang (in V2Upgrade branch).
At this precise moment the sister command :MOVETOIMPL doesn't work as expected with constructors defined with initializer-lists, which has side effects on the :Constructor command. :MOVETOIMPL is meant to change an inline definition into a declaration plus a separate definition in a .cpp file typically.
Note: lh-cpp is a complex plugin that provides many things and that has many dependencies. Regarding overriding, it provides an :Override command to let us select which function we want to override -- this feature requires my current working branches of lh-cpp and vim-clang.
If you are using Neovim, you can try my plugin: cppassist.nvim, which can basically be used normally, but there are still many problems. Welcome to ask me questions!
This plugin will recursively search in your working directory until a file matching the same name with the counterpart extension is discovered. Note that the search also respects your .gitignore if one exists and any file ignored in git will be ignored in the results. As such, I suggest working from the root of your project. Once that file is found, it will automatically be opened in the current buffer. If no corresponding file is found, a message will be logged to the messages buffer -- use :messages to review your recent messages.
It uses regular expressions instead of LSP to generate function definition. Currently, it supports most keywords, as well as template types, and can generate multiple function definitions simultaneously in view mode.
However, the definition of nested classes is not currently supported. Also, if the function definition is already generated, press the shortcut key again and it will generate the function definition again.

Pycharm docstring: code references and docstring inheritance

I'm currently going through my project in Jetbrains Pycharm 2017.1.5, documenting all my python 3.6 classes and methods, and several things stand out to me about the docstring format.
I want to link to other methods / functions / classes from some of the docstrings, but I cannot figure out how to do this. The documentation for restructuredText is very, very extensive, but it doesn't say anything about referencing other docstrings with Pycharm. In fact, the vast majority of the snippets from that page do not even work in Pycharm. (Why is that?)
I've managed to find that you can use :class:`<class_name>` to reference a class, but :class:`<class.method>`does not work, and similarly named constructs like :func:`<func_name>` do not create a hyperlink. I've also seen :ref:`<name>` come up, but that one doesn't work either.
(I would switch to Epytext (it has everything I want, plus it's much simpler) in a heartbeat if not for this error: You need configured Python 2 SDK to render Epydoc docstrings in the Ctrl + Q frame.)
It would also be extremely helpful if there was a way to inherit the docstring in subclasses / overridden methods. Pycharm does this automatically if you leave the docstring blank, which makes me think it is possible to do it manually. But, again, I can't find any information on it.
It's turning out to be mind-blowingly complicated to do something so, so simple. So, any help will be appreciated!
I want to link to other methods / functions / classes from some of the docstrings, but I cannot figure out how to do this.
You're correct that the reStructuredText documentation does not cover this, because it's not a feature of reStructuredText.
Likely you are (explicitly, or implicitly via some tool) using the Sphinx system – a superset of Docutils – to allow (among many other features) references between different docstrings.
Sphinx defines several Docstring “roles” (the :foo: before the backtick-quoted text) for different purposes:
doc, a reference to an entire document.
ref, an arbitrary cross-reference.
… many others.
For specifically Python code, the “domain” py has its own specific set of roles for Python code docstrings:
:py:mod:
Reference a module; a dotted name may be used. This should also be used for package names.
:py:func:
Reference a Python function; dotted names may be used. The role text needs not include trailing parentheses to enhance readability; they will be added automatically by Sphinx if the add_function_parentheses config value is True (the default).
:py:data:
Reference a module-level variable.
:py:const:
Reference a “defined” constant. This may be a Python variable that is not intended to be changed.
:py:class:
Reference a class; a dotted name may be used.
:py:meth:
Reference a method of an object. The role text can include the type name and the method name; if it occurs within the description of a type, the type name can be omitted. A dotted name may be used.
:py:attr:
Reference a data attribute of an object.
:py:exc:
Reference an exception. A dotted name may be used.
:py:obj:
Reference an object of unspecified type.

Creating libraries that can be imported and used in Groovy

Currently, I am working on a project to transpile from my company's in house scripting language, which is Object Orientated and takes quite a few features from other languages, into Groovy, which has many similar features.
To keep code as close to original as possible, I am trying to leave certain function names and parameters the same. To cater for this, I would like to write a set of libraries that can be imported.
For example, say I have an inbuilt method in the original scripting language,
I would like to be able to write the definition for this method in a groovy file, that can then be imported when needed, and the method may be called.
Tools.groovy
// filename: Tools.groovy
public String foo(String bar) {
return bar;
}
and in another file
Main.groovy
// filename: Main.groovy
import Tools;
String bat = foo("bar")
I know you can can compile class files into jars and put them into the class path, but a lot of the methods I will need to implement will either require meta programming or won't be associated with an object.
Sorry if it's either a bad question or not clear enough. I'm not sure whether its even possible.
Cheers
I believe you should be able to create libraries and reuse them when needed.
All you need to do is create class and add the static methods if you do not have to create instances, non static methods otherwise. Then it looks like you already aware how to proceed later.
For instance, you can create utilities classes for String, List, etc based on your description.
By the way, even if you do not create libraries, it is even possible to write one lines in groovy achieve what you may needed most of the cases.

How to prevent dead-code removal of utility libraries in Haxe?

I've been tasked with creating conformance tests of user input, the task if fairly tricky and we need very high levels of reliability. The server runs on PHP, the client runs on JS, and I thought Haxe might reduce duplicative work.
However, I'm having trouble with deadcode removal. Since I am just creating helper functions (utilObject.isMeaningOfLife(42)) I don't have a main program that calls each one. I tried adding #:keep: to a utility class, but it was cut out anyway.
I tried to specify that utility class through the -main switch, but I had to add a dummy main() method and this doesn't scale beyond that single class.
You can force the inclusion of all the files defined in a given package and its sub packages to be included in the build using a compiler argument.
haxe --macro include('my.package') ..etc
This is a shortcut to the macro.Compiler.include function.
As you can see the signature of this function allows you to do it recursive and also exclude packages.
static include (pack:String, rec:Bool = true, ?ignore:Array<String>, ?classPaths:Array<String>):Void
I think you don't have to use #:keep in that case for each library class.
I'm not sure if this is what you are looking for, I hope it helps.
Otherwise this could be helpful checks:
Is it bad that the code is cut away if you don't use it?
It could also be the case some code is inlined in the final output?
Compile your code using the compiler flag -dce std as mentioned in comments.
If you use the static analyzer, don't use it.
Add #:keep and reference the class+function somewhere.
Otherwise provide minimal setup if you can reproduce.

Boo - Excel Automation, trouble selecting ranges

I'm investigating Boo and thought it would be a useful exercise to try converting a couple of venerable VB Scripts that automate Excel (2007, in this instance). A lot of things seem to translate very easily, however I'm having a huge amount of trouble selecting ranges - whenever I try to get or set them I get a TargetInvocationException Member not found.
Here's a (cut down) example I've run in booish:
def CreateInstance(progid):
type = System.Type.GetTypeFromProgID(progid)
return type()
xl as duck = CreateInstance("Excel.Application")
xl.Visible = true
xl.Workbooks.Add
sht as duck = xl.ActiveSheet
#Next line throws exception
rng as duck = sht.Range("A1")
Certain things work fine, such as setting the Name property of the sheet and so on, but how do I work with ranges? Are there some special methods that VB hides that I'd need to call, and if so how would I go about finding those out?
Cheers,
Lenny.
Range is actually a property, and it's a somewhat special property in that it works as an Indexer, which means that it has array- or dictionary-like semantics. In most languages, that means that you'd access sht.Range["A1"]. That is syntactic sugar, and really it's accessed just like any other method, namely:
sht.get_Range("A1",System.Reflection.Missing.Method)
I attempted to use Boo, Ruby and IronRuby to repeat your code, using both the syntactic sugar style and the explicit method call. In IronRuby, I can get it to work flawlessly, but only in the 32-bit interpreter. In regular Ruby, which is a 32-bit app on my configuration, it also worked fine. In the 64-bit interpreter, the Range property was never resolved correctly.
So that led me to suspect that the Boo Interactive Shell was running in 64-bit mode and that interop was failing because of that. Unfortunately, the same issues reproduced after setting my local Boo binaries to run in 32-bit mode using CORFLAGS.exe, so I don't think that's the real issue.
What did work, though, was to explicitly import the Excel Dotnet Interop Library as well as the Interop services namespaces, like so:
import Microsoft.Office.Interop.Excel
import System.Runtime.InteropServices
xl_type=typeof(Application).GetCustomAttributes(typeof(CoClassAttribute),true)[0].CoClass
xl=xl_type()
xl.Visible=true
xl.Workbooks.Add
Then:
xl.Range["A1","A2"].Value=12
xl.Range["A1",System.Type.Missing].Value="Alpha"
(xl.ActiveSheet as Worksheet).Range["A1","A2"].Value2='Whatever'
All of these work, but they essentially require you to give up the "Scriptiness" you're used to from late-binding (which is what your duck typing is doing).
One difference from VB/VBScript that is true for most languages (other than C# 4.0) is that, generally, optional parameters are not handled transparently, so you'd need to look at the API more carefully when you deal with methods that support optional parameters (replacing them with System.Type.Missing or the System.Reflection equivalent). You'd find this through the Excel interop docs, although you can probably use reflection to identify parameters marked as optional if you find that easier than looking it up.
Because Ruby has a reasonable solution for late binding these objects, I suspect there's a missing feature (or bug) in COM interop scenarios in Boo.
Edited to add: Sam Ng writes about indexed property support in C# 4.0; the issues described in his post likely apply to Boo, as well.

Resources