Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
While working on a Spring Boot project I got this doubt that what is better to use to Save Constant Values, application properties file or a Java Interface?
To get value from application.properties we have to declare variables in every file where for Java Interface, we will have only one declared variable referred everywhere.
Any other advantage one over other. Can anyone figure out in terms of memory efficiency?
The advantage of using application properties is you can change the value without changing code. If you think something is likely to change, or if it is different for different environments, then it would make sense to put it in the properties. You can define multiple profiles and have a properties file for each profile if needed.
If you are sure something isn’t going to change then define a constant. In that case you’re assigning a name to a value to improve the readability of the code.
This kind of thing seems unlikely to be significant enough for it to matter for performance. Performance improvement is about identifying and addressing the biggest bottleneck. This is going to be a long way down the list.
Using application properties file to save constant is preferred.
You can check this link for detailed explanation:
What is the best way to implement constants in Java?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
As in java8:
someList.stream().map(e->e.getXXX()).toList()
For example, I have a Student array/slice, and the struct Student contains properties like Id, Name, and so on.
I want to extract all Ids into a NEW array/slice with one-line code like java8 as mentioned above, instead of range. Is there is an example?
Currently there is not an easy, builtin way to do this. Although Go has first-class functions and lexical closure, it's not possible to write a function like map that will operate on arbitrary types in the way you want. (Also, there's no compact lambda syntax, but I consider that a relatively minor issue).
Instead, you have to do one of the following:
Operate on interface{}. While this would let you write a func map([]interface{}, func(interface{})interface{}) []interface{}, you lose compile-time type safety, you lose performance, and a []interface{} is not a []string (or whatever the type is of the field you wanted to fetch), nor can you even type-assert it to one, so working with the result is cumbersome.
Use code-generation. There are libraries out there that will generate map/filter/etc. code for you, specialized to given types, so that none of the disadvantages of #1 apply. And Go ships with a Go parser in the standard library, so most code generators are fairly robust. But code generation is a separate build step, hampers debuggability, and can hurt the clarity of code.
Just live with boilerplate, writing lots of loops, and forget about trying to achieve functional style.
Wait for Go 1.18 to bring generics, which should make libraries of functional idioms a lot more practical.
Most experienced Go users would recommend approach #3, and so do I (reluctantly).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
When creating a webserver in golang, is there any specific reason why JSON data would be represented as a MAP over a STRUCT or vice versa? ..or is this decision based purely on user preference ?
I think this discussion could go either way but the advantages of using structs vs maps are that structs give you an idea of how the schema should look like whereas a map leaves the schema open-ended.
If you use structs, developers who look at the code will have a clear idea of what parameters you're expecting for the API or how the response of the API may look like without digging further into implementation detail. On the other hand if the requests or responses were maps, they would have to look at the implementation detail to see what keys and values are being assigned. Hope this helps!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm re-evaluating SONAR code quality rules after upgrade to 4.4 and here is strange CheckStyle rule called 'inner type last' which is part of class design group and actually recommends to place inner classes AFTER everything including methods.
What motivation is behind this? I never expected someone to consider this approach as useful but maybe I have missed serious ideology? Checkstyle rule definition doesn't provide any ground neither quick googling (maybe I searched wrong way). Could you please point from where this comes?
This rule assumes that inner types are "side" types that deal only with internal details of the enclosing type, and so that it's not worth showing those details at the very beginning of the source file to not focus attention on them.
IMO, the only (very little) value of this rule is to ensure consistency of code structure across your source code.
Well ... this is indeed a mostly useless rule, especially because it cannot currently (5.7) be configured to enforce inner classes being declared at some other position than at the end. It can safely be disabled, I think.
However, it is the only way to enforce this part of the source file structure, so if you cannot be sure that everybody has her/his formatter properly configured, you might even want this. (Personally, I prefer inner types at the top, so that I know what they are when I read the code that's using them.)
The Checkstyle rules were originally focused on the Sun Code Conventions (1999), which did not say where inner classes should go. Also, the newer and popular Google Java Style (2014) has no opinion on this. Checkstyle even has a DeclarationOrder check, which also cannot check inner class position.
So I guess someone finally said this had to end and added InnerTypeLast. And there we have it. :-)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What do you think fellow programmers about using short functions vs using inline code?
Example with function:
//Check if all keys from $keys exist in $array
function functionName(array $array, array $keys) {
return array_diff($keys, array_keys($array));
}
functionName($mas,$keys);
vs. using just the code:
array_diff($keys, array_keys($mas));
I think that in your example, it's superfluous. There's no need to create an extra function call and add bytes to the filesize without good reason.
Also, the inline array_diff($keys, array_keys($mas)); is a lot easier to debug for fellow programmers, than looking through your code to find out exactly what functionName() does and where it is located.
It depends on what functionName actually is.
If you're using customerDetailsAreValid throughout your code and you suddenly have to add validation of $array['email'], you're going to be grateful for the separation of intent and implementation.
If on the other hand you're wrapping array_diff in the function diffArray there isn't much point.
I think clarity is a prime concern when writing logic you hope will be around for any amount of time.
In general, I abhor inline functions. I think they are lazy, promote spaghetti code, and in general exude a complete lack of concern for style/readability/clarity on the part of the developer.
Filesize - I find this argument very arbitrary. The js files are transmitted once and then cahced. In many cases, you find descriptive names, etc, (hopefully comments) that all add to file size. If size is very important , use a file minimizer that makes a file as tiny as possible.
Looking for a function? How about trying to figure out exactly what is going on in a voluminous docReady. CTL-F usually invokes a find facility.
I will grant that there can be simple cases where an inline function detracts little from the readability of the code. However, the inline approach will never be MORE CLEAR than the alternate separation of reference and implementation.
my two cents
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
There is a Style Guide for Protocol Buffers. But it does not clearly say how a .proto file should be named.
MyProtos.proto, my_protos.proto or my-protos.proto, which is the better name?
I don't believe there's an appropriate answer to how any file "should be named" other than aim for consistency and clarity.
Consistency would mean following the file-naming conventions your project already has for sources and headers. If your sources are named using camel-case, do the same for the proto files. The most common choice seems to me to be the my_protos.proto version.
Clarity to me means that the file name should give some clue as to the contents. I generally favour naming files after the class which they implement, and usually have a separate file (pair) per class. I would recommend the same for the proto files. I prefer several small proto files each defining a single Message or very closely related Messages over a single huge proto file defining all your Messages in the one place.
Since the question is almost 8 year old, for those who people looking at this in 2020 s, now there is a style guide published by google.
Excerpt for file naming
Files should be named lower_snake_case.proto
https://developers.google.com/protocol-buffers/docs/style