You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to propose software metrics for the Language Server. Possibly this is not the right place, then I apologize. Maybe I didn't understand something technical correctly, then I apologize for that as well.
Jim Wanner, the author of one of my favorite tools has ended his career as a software developer. With SourceMonitor, I was able to view various software metrics about source code. This is a great support to write better code. It is also a great help for restructuring and improving code. Unfortunately, there will be no further development for this tool.
So I had the idea that this could be a topic for the Language Server. The Language Server is available for many programming languages. Then no programming language specific plugin would be necessary, all languages could profit from a uniform interface.
A few metrics are easily implemented: The number of lines in the file, the number of lines of code, the number of comment lines, ... It gets more elaborate with the McCabe metric (cyclomatic complexity) or the branch depth. It is even more complex if this is to be done not only for a single file, but for a workspace. Then there are the average values and a maximum in addition to the previous values.
From my point of view this would be a great feature. Since I use VSCode very often, this would be enormously helpful in my daily work. I use VSCode with Pyhton, C/C++, C#, JavaScript, HTML and CSS, sometimes for Ruby and others.
What do you think about this, would it be possible?
thank you for your comment. I lack knowledge about the architecture/parts that make up VSCode.
My guess was that the desired function could be a part of the language server. As far as I understand, the server provides all language specific functions. I also assume that the calculation of code metrics could be somehow language specific. For example, there is no switch/case statement in Python, but there is for C/C++, C# and Java. Each language has its own syntactic and lexical properties.
My idea was to build some kind of interface for metrics into the language server to provide the information for each client. Because each language has its own language server, parts of the code could possibly be reused to compute the metrics as well. The language server maintainer(s) could add this metrics information with less effort.
If I am informed correctly, for example Eclipse also uses the language server. Is Eclipse also able to use the generic request you suggest? If so, that could be a good way to provide these metrics.
Note that LSP isn't really intended to spec the content of the various language assistance, but instead to specify the interactions and workflow that do happen when providing assistance for file edition.
It seems to me that what you are willing to discuss is about the content; and that there are already interactions existing in LSP to cover that: complexity can be shows as codelens, as hover information or as diagnostics... So LSP seems complete for your case and it becomes just a matter for you to build or extend a language server to add the information you want where you think it fits best.
IMO, this issue can be closed.
The requested feature is not part of the language server protocol.
The feature should be implemented at the language server itself.
To visualize the software metrics on client side, e. g. in Visual Studio Code, many different ways are possible. A generic CodeLens request could be one of the ways, another might be hover information or diagnostics like Mickael Istria (@mickaelistria) proposes.
So I have to request the feature in the vscode-cpptools - the language server implementation for C/C++? Maybe there's again a misunderstanding from my side - in this case I'll be happy about any hint to get me in the right direction. Then this issue can be closed - I agree to Mickael Istria (@mickaelistria) .
Activity
dbaeumer commentedon Aug 9, 2021
Jochen Paul (@ThirtySomething) can you explain why this can't be implemented using the generic CodeLens request (see https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_codeLens) I do know that some metric tools for VS Code use that approach.
ThirtySomething commentedon Aug 9, 2021
Hello Dirk Bäumer (@dbaeumer) ,
thank you for your comment. I lack knowledge about the architecture/parts that make up VSCode.
My guess was that the desired function could be a part of the language server. As far as I understand, the server provides all language specific functions. I also assume that the calculation of code metrics could be somehow language specific. For example, there is no switch/case statement in Python, but there is for C/C++, C# and Java. Each language has its own syntactic and lexical properties.
My idea was to build some kind of interface for metrics into the language server to provide the information for each client. Because each language has its own language server, parts of the code could possibly be reused to compute the metrics as well. The language server maintainer(s) could add this metrics information with less effort.
If I am informed correctly, for example Eclipse also uses the language server. Is Eclipse also able to use the generic request you suggest? If so, that could be a good way to provide these metrics.
dbaeumer commentedon Aug 10, 2021
I am not sure about Eclipse. You need to ask them whether they support CodeLens. But I think there is a high change that they do.
mickaelistria commentedon Aug 10, 2021
Eclipse IDE integration for LSP (aka Eclipse LSP4E project) has had support for codelenses for more than 3 years now. See http://www.eclipse.org/community/eclipse_newsletter/2018/june/images/let_example.png for instance of how this looks.
mickaelistria commentedon Aug 10, 2021
Note that LSP isn't really intended to spec the content of the various language assistance, but instead to specify the interactions and workflow that do happen when providing assistance for file edition.
It seems to me that what you are willing to discuss is about the content; and that there are already interactions existing in LSP to cover that: complexity can be shows as codelens, as hover information or as diagnostics... So LSP seems complete for your case and it becomes just a matter for you to build or extend a language server to add the information you want where you think it fits best.
IMO, this issue can be closed.
ThirtySomething commentedon Aug 11, 2021
Mickael Istria (@mickaelistria) Dirk Bäumer (@dbaeumer) Thank you for the provided informations. What I understand is:
So I have to request the feature in the vscode-cpptools - the language server implementation for C/C++? Maybe there's again a misunderstanding from my side - in this case I'll be happy about any hint to get me in the right direction. Then this issue can be closed - I agree to Mickael Istria (@mickaelistria) .
ThirtySomething commentedon Aug 14, 2021
I've startet a discussion here and opened an issue here.