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
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 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 last year.
Improve this question
I suspect this question has been asked before, but it's not easy to Google for.
I am a fairly new coder and I see a lot of code, in a lot of different languages, with comments beginning "TODO".
Questions:
Is there a practical reason why people write TODO in all these different languages, or is it merely a convention?
If the latter, where did the convention come from?
I can see why it's useful to be able to grep for TODO, I'm just curious about the history behind it.
Programming is a world-wide activity; conventions to help smooth the process of working with people who are not native speakers of each other's languages are worth their weight in gold. TODO, XXX and FIXME are often highlighted by IDEs, which provides an excellent incentive to stick with these options.
XXX suggests a danger or hazard that maintenance programmers must be aware of;
FIXME insinuates that something is wrong with some implentation which needs to be changes;
TODO explains shortcomings that would be nice to address.
TODO means "to do". Something that someone will need to do. Just guessing, but could this guess be wrong?
Just a quick follow up to the original answer:
This feature is mainly a reference and you'll find it in Frameworks if there are items that aren't detrimental to the code still running, but that the developers would like to address.
The nice thing about modern IDE's, for example I use JetBrains PHPStorm, they actually highlifht TODOs and place them into a Toolbar for your entire project so you can see all the TODOs for all your files differentiated by their directory and file name.
Anyway, just thought this may add further light as to why you may see it throughout code.
In addition to the comments about grepping, editor/IDE identification etc. I would think that a big reason as to why TODO became the standard, instead of say todo or ToDo, is simply that TODO is a big todo.
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 7 years ago.
Improve this question
I'd like to write a code beautifier and i thought of using Ruby to do it. Could someone show me a place to get started? I've seen a lot of code beautifiers online but I've never come across any tutorials on how to write one. Is this a very challenging task for someone who's never undertaken any projects such as writing a compiler, parser, etc. before?
(Is there another langauge which would be more well suited for this kind of task, excluding C/C++?)
Python has an interesting feature - it exposes its own parser to scripts. There are examples that use the AST - abstract syntax tree - and do the pretty printing.
I'm not aware that Ruby exposes its own parser to its scripts in such a way, but there are parsers for Ruby written in Ruby here.
Well... I think the initial steps are what you'd do for any project.
Write a list of requirements.
Describe a user interface to your program, that you like and won't prevent you meeting those requirements.
Now you can write down more of a "code" design, and pick the language that would be easiest for you to meet that design.
Here's some requirements off the top of my head:
Supports code beautifying of these languages: Ruby, Python, Perl
Output code behaves identically to input
Output has consistent use of tabs/spaces
Output has consistent function naming convention
Output has consistent variable naming convention
Output has matching braces and indentation
Make as many as you want, it's your program. ;p I was kidding about the Perl, but I think every language you support is going to add a more work.
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 4 years ago.
Improve this question
In API documentation, and sometimes even used in discussions here on Stack Overflow, I sometimes see the pound (#) character used instead of the dot (.) as the separator between the class name and the method name. For example:
Settings#maxPageSize
I'm wondering what this usage means, and where it comes from?
Assuming you mean Ruby (which is the first language that I can think of with such conventions), it is explained here:
Why are methods in Ruby documentation preceded by a hash sign?
I've always thought that the distinction is that Settings.maxPageSize seems to imply that you can actually write just that (i.e. that it is a static method), and that the pound is there to denote that it is just a reference to a method, not a piece of code that you can execute.
Although I could be totally wrong about this =)
So for static methods, you could actually reference them Settings.maxPageSize, but for instance methods, you'd have the option of coming up with a new convention, such as Array#sort to denote that something special is going on, or, to achieve the same completeness, you'd have to write
myArray.sort // when myArray is of the type Array
EDIT
Amadan's reply seems to confirm my interpretation, with the exception that Settings.maxPageSize is not used for static methods either; rather, that would be Settings::maxPageSize, and . being reserved entirely for example code, which makes sense to me.