We Keep Coding

Tracing the execution of a method using log inside a method is bad practice? [closed]

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 currently developing a restful service using spring MVC.
I have read that logging is a cross cut concerning so I was wondering if it is bad practice to have log statements like log.info("A variable value") inside service facade methods.
Should we remove those log statements and put them inside an interceptor kind of object whose single responsibility is logging?
Is a method full of log.debug messages whose responsibility is to help tracing the method execution bad practice? If it is, how can we move this responsibility to a interceptor if the interceptor only have access to the method parameters
If I need a more informative tracing execution how can I achieve that?

If you do not understand what a method is doing there is a major problem, you have lost control of the software.
There are times when it is needed but should be removed as soon as possible. Among other things log statements make understanding the code more difficult by adding non-logic "noise".
Methods should be small enough that they are easily completely understood with only a small effort, with only a few exceptions. See "Uncle" Bob Martin.
I was brought in on one project because the performance way unusable slow. I solved that problem in a day, it was the logging, I removed it and the performance increased by a factor of > 25x.

It's not necessarily bad practice, but you should try and avoid the mistake twitter made where it's logging messages had user passwords in plain text before encryption

Restful API, good practices [closed]

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 6 years ago.
Improve this question
This question is more about design than a technical problem.
I'm developing a backend application using java and Spring Rest Services.
It is a small application so in the beginning I just created a controller for all the end points (5 or 6 end points). I have for example an endpoint to request a token i.e /token, and another to make a request, based on the token received previously i.e /readresource.
So now I'm wondering if I should split the controller into two or more controllers, each one with the end points that are related to each other.
Of course in terms of legibility of the code this is useful, but also, from a technical point of view, if the default scope of a spring bean is SINGLETON, if I have only one controller, that would make only a single instance for the whole application, so let's imagine we have two requests that arrive to the server at the same time, even if each request is running a completely separate thread, and they are requesting different end points, in the end they are accessing the same instance so, one request should wait for the other to finish, we cannot execute on the same instance two different threads at the same time, am I right?
So... in terms of performance or good practices, is it better to avoid big controllers with many end points to have instead many small controllers?
What do you think about it?
Thank you!

we cannot execute on the same instance two different threads at the same time, am I right?
Wrong. This is only the case if the method that is being called has the synchronized access modifier. Otherwise, concurrent calls can occur on the same instance in different threads.
Having multiple controllers has no obvious impact on the performance of the application. It means an extra bean is loaded into memory, which equates to a few extra KB of RAM taken up.
This cost is far outweighed by having code that can be read and understood easily. Remember, you shouldn't write code for yourself. You should write it for the next guy, or as a man much smarter than myself once said..
Write your code as if the next person to read it is an angry psychopath, and he knows where you live.

Should i use for each loop/cursor in SQL or a regular one in Java? What is more efficient? [closed]

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 6 years ago.
Improve this question
Hello stackoverflow i have a doubt, which is the proper way to solve this?
I have this sql sentence:
SELECT *
FROM task
, subject
WHERE task.id_subject = task.id
AND task.id_tasktype = 1
AND subject.id_evaluation = {ALL the ids of table evaluation}
If i want to execute this sentence for every evaluation what is more efficient? a loop/cursor or whatever in SQL (i have basic knowledge of sql) or a regular for each in Java?

It depends on your situation. Basically, if your database server and application server are actually two different computers, then you might decide to run the loop at the server which can handle more pressure. You need to look at some statistics to be able to determine this.
Also, you can implement both solutions and measure the time needed at db server + time needed at application server. If one of your loops is consistently quicker than the other, then it is practically more efficient in the scenario you are running it according to your experiments. Off course, the scenario might change over time.
Generally speaking, people tend to run this loop on the application server (Java), since you might need to execute some things available only there in the future, but if you have a very good reason to run this on the database server, like the case when a trigger should trigger this functionality, then you might decide to run it there.
Basically, you are trying to optimize a loop where you do not necessarily have a problem. If you encounter performance issues, then you might decide to experiment with a few things, including, but not limited to the suggestions shown in your question.

Create too many classes or have some schema-less data structure(like dictionary)? [closed]

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 8 years ago.
Improve this question
I'm have to use 50 different custom datatypes(/classes) which are defined in a document(xml/json), they have only fields and no methods and maybe strong validations.
My question is should i go ahead and create(/generate) 50 classes or use some generic data structure (like HashMap<String,Object>)?
Update: My fear is if i go with class geneartion, then my codebase might increased by very much
and if go with schema-less way, my data integrity might be compromised, so which one is lesser evil.

Unless it is just ridiculous, more code is more forgivable, in general. There are a few different reasons:
If you give them base classes at the right points, you can have it both ways, as your handling code can hold the base classes, and may have anchor points for extracting, validating or cleaning information stored in the different formats. Surely some of the processing can be shared.
If absolutely everything really falls to the base class, you can refactor the sub-classes out of existence without pain. On the other hand, if you start the amorphous way, gathering the special cases back into separate classes is more likely to go wrong.
Excessively large code is only bad if the extra volume does not clarify the logic for readers. I would have the classes, if they constitute units in which people think.
Also, actual functionality is more important than format or even readability. So if the risk is to data integrity vs code bloat, protect the content, not the form.

What would be your interpertation of this requested queue implementation? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I had been reading two books on JAVA and while covering data structures, I started to do some online research with regards to "QUEUE" implementation. I have an extensive background in FLEX, however ACTIONSCRIPT isn't comparable to advance languages.
Lets say if I was on a job interview and asked to implement a Queue of Object, how should I pursue it as? I am not looking for code help here, I would like to what would you quick answer be? I have been to Java online docs and do understand there are 13 known implementing classes, and "LinkedList" is one of them.
Google search has return more results with "LinkedList" implementation code than any other.
My apologies if you find this question to be rubbish or pointless in anyway.
Oracle's Java online doc ref:

Do you know what the concept of a queue is and how it differs from a stack (closely related data structure)? If so, you should be able to think of multiple ways to implement it.
Which is best depends on the exact requirements of the task it's being used to address.
So the right response to that interview question is not to start coding but to ask them for more information about the requirements your implementation has to address. Performance? Memory size? Multitasking? Any limits on maximum queue depth, eg to guard against things like a DOS attack? What's being enqueued -- objects, primitives, other? Specific kinds thereof? Parameterized type? Are there any values which should be discarded (maybe null shouldn't be enqueued)?
Knowing the requirements, you should be able to judge which answer is appropriate. Starting coding without asking the requirements is immediately going to earn you a demerit.