IT has a huge impact on climate and is responsible for part of the changes to come. Using and developing programs that restrict their impacts on the climate should be the norm and development teams should be urged to use practices, tools and designs that help in offering such virtuous software: “low carbon impact” should be considered as a great quality criterion.
SQ is a great tool to monitor software quality and as such it should offer the ability for development teams to track and follow the carbon impact of their work. The request is to add measures in SQ that people can feed and use to monitor the carbon impact of their programs. We already have some simple metrics that we could use to feed these measures: Web page weight, number and average weight of the requests between the front-end and back-end, etc.
It is not an easy task to feed such measures: additional plugins shall be created in this purpose, but SQ should be ready for this and offer the opportunity to take an active role in the uttermost goal that is coping the climate change.
thanks for raising this topic, you can’t imagine how happy I am to see people care about the climate.
To me, SonarQube (at least in its current form) can’t be the tool for those needs. SonarQube is strictly source-code centric, it’s all about source code static analysis and it is designed to report problems found on lines of code during automated CI/CD processes. The metrics you started listed can not be managed by SonarQube:
the weight of a Web page cannot be linked to a source file (it’s a combination of many files)
the requests between the front-end and back-end can hardly be gathered during a CI/CD workflow
I know a company who’s jumped into this topic: https://greenspector.com. It’s a really specific domain on its own.
On SonarSource side, the “only” thing we could do (and that could already be great!) would be do find what kind of issues we could find during static code analysis, that we could correlate to reducing the environmental footprint of a code base.
I understand your point of view. My first intention what to “lancer un pavé dans la mare” to see if people are caring about IT’s environmental impacts
I know it is very hard to find issues that could correlate to an environmental footprint. So far my guessing is that environmental metrics mostly come from dynamic tests but still there are some static metrics we can use. As an example I can mention dependency management: if you are able to measure and compare a dependency’s impacts then you can identify an issue for applications using the less performing version of a framework.
Consequently, I do not really request new metrics but instead at the moment have the ability to define our own metrics and/or measures that we could feed with some specific or custom plugins. Maybe it is already possible but allowing plugins to define new measures, which we could use in quality gates, would be great because people could develop their own custom plugins with whatever they think could measure an environmental impact and assess their developments against that.
Thanks @Fabrice_Bellingard for your answer.
I up this post because i think it was maybe not an important point 2 years ago but right now it’s a major point to discuss : how to deal with climatic impacts from code !
Many companies have changed their purpose and the laws are moving in the direction of imposing the eco-design of digital applications.
I agree with your explanation that SonarQube is here to analyse static code only, but i think the static code is sufficient to raise indicators.
My proposition :
Today, we have 4 default rule types :
Type : Bug, Vulnerability, Code Smell or Security Hotspot rules.
=> Add new default one : “Green smell” type (or another naming)
How to measure it ?
=> Add new rules into each langage rules list
Or maybe we can tag an existing rule with 2 differents types (ex : Bug and Green smeel), but i don’t know if this is possible.
By this way, each langage will be able to show an indicator of bad green practices
And we can begin with one langage do it incrementally on each langage supported by SonarQube.
Result :
0 “Green Smell” => Green indicator
1 to 10 “Green smell” => Orange indicator
10 and more => Red indicator
Maybe a plugin can do it.
But it will be more noticeable if SonarQube takes this way and pushes this functionality by default.
This will have more impact on the environment and on the image of SonarQube
PS : I’m SonarQube user and not SonarQube expert, so maybe something I said is not possible.
I’m pretty sure we can find a good and easy solution by discussing about it !
What you suggest would make sense, as long as we can actually create rules that can detect bad coding practices which lead to inefficient execution of the application (to put it simply). And for me, this is the most critical (and probably difficult) point to clarify.
Do you have in mind examples of rules which would feed “Green” indicators?
Here are some examples of the rules I have in mind :
Cut CCS files if all CSS conditions are not in use on a page (to reduce HTTP requests)
Use abbreviated CSS notations to reduce the weight of the stylesheet.
Do not write : margin-top:1em; margin-right:0; margin-bottom:2em; margin-left:0.5em;
But write : margin:1em 0 2em 0.5em;
Always provide a CSS print to reduce pages to print
use standards police (available on systeme and not necessary to download it)
externalize CC and JS code and not include on HTML files
Define media queries to display web site on mobile and use specific styles to save bandwidth on loading non-identifiable elements on this type of screen
remove code not used
Convert images to WebP
Not use external libraries that are obsolete or known to not be optimized
Do not use iframes
Not use frameworks that are obsolete or known to not be optimized (ex : angularJS in dec 2021)
Do not use timers (setTimeout or SetInterval in JS) below the system task sequencing limit (ex : Windows is 15,6ms)
Do not use fresh page methods but prefer use ajax <meta http-equiv=”name” content=”bar”>
Or Javascript location.reload(true);
Use event delegation
do not modify many css syles in one time, prefer modify class
Prefer to use a logic test to the use of try…catch…finally
Use primitiv operations
Do not write : var min = Math.min(a,b); A.push(v);
But write : var min = a < b ? a : b; A[A.length] = v;
it is better to use anonymous functions
Give functions as parameters to setTimeout () and setInterval () rather than strings
Avoid “for … in” loops
Reduce access to the DOM via JavaScript
Replace $i++ by ++$i
…
I have many and many rules to give you as examples (especially concerning javascript in my case).
But we can find same bad “green” practices in others langage too.
Many on my examples came from Green.IT guide Collectif conception numérique responsable (greenit.fr) and have real explaination.
I am obviously interested in helping to implement it via SonarQube if possible
@glalloue
These rules are extracted from the book “115 bonnes pratiques d’éco-conception” of Frédéric Bordage isn’t it ?
I am really interested in that field and I have been looking for some help in my development of a Sonar Plugin that could give some metrics to have a feedback on code quality in terms of climatic impacts.
As I am newly graduated from an engineering school, I don’t have enough experience to go far in this development. Sonar environment is new for me and this point complicates more this task.
Hi @gatbi & @ grapinmat
Before to give you an answer, I have a question for you :
Do you speak french and are you currently member of the green IT community led by frédéric bordage?
@gatbi : Yes, my examples are extracted from the book “115 bonnes pratiques d’éco-conception”
But I’m also working on adding more “codable” rules on my list.
About SonarQube, I’m just user of this tool for now and i don’t know how to make Plugins, but maybe I will look into the question if this is the solution to integrate a new indicator.
We are in the process of creating a working group on SonarQube within the Green IT community, but it is a group only speaking in French for the moment, that’s why I asked you the question.
if you are interested I suggest you send me an email at geoffrey.lalloue@orange.com
It’s great to see that other people are interested in the subject.
@Fabrice_Bellingard : I sent you private message on linkedin to talk about this subjet more in details. Do you think the sonar team can support us on this subject?
As far as I can read, most contributors in this topic are French speaking persons so this should not be an issue. @glalloue Gabin and I are working together, we’ll send you an e-mail along. We’ll be glad contributing to this working group (at least myself on my personal time if we cannot find an agreement with our company).
To cover the dynamic aspect of code, I can mention my experience about integrating SQ with 3rd-party tools (e.g. m Shellcheck or ansible-lint plugins): this is something that is feasible (I mean: after running and analyzing the code/application dynamically, a tool may generate a rzsult file that is read and imported into SQ via a plugin, centralizing the information and taking into account the dynamic behaviour of the application into quality gates).
Last but not least to continue with such integration, I sent an e-mail a while ago to info[at]greenit.fr about the ecoindex and the option of committing this tool to the Open Source community (without access to the result database, as I understand this can lead to legal issues or whatever) so that we can integrate it into CI/CD piepelines, giving an interesting feeback on applications while they are developed, but I did not get any reply.
Hello,
if anyone is interested in joining this “green” sonarqube plugin project, you can subscribe to the cnumr Slack (in french) or ask to join us by filling contact form here : Collectif Conception responsable de service numérique (greenit.fr).
Or (if you have no answer from contact form), send me message by email : geoffrey.lalloue@outlook.com (my previously mentioned “orange” email address is no longer usable)
