Office Hours Transcript: 2021-12-04
Kai_H joined
hello, Kai!
how can I help you today?
Hello Mark
Just lurking atm
OK
About comments in code: Where and when do you use them? Are you a proponent of "comment all the things" or rather "have almost no comments"?
Where and when do you use them?
that depends largely on the circumstances of the project
book samples? few comments, because I am explaining things in the book
projects for which I am a team member? whatever their approach is
I mean in a real project, for yourself or a customer.
Do you have a preference?
everything else? my default would be to comment the public API and anything that might be confusing
I got an offer to work as a Kotlin backend dev at a startup and am trying to decide about it. One of the things they do is go almost without comments, and I don’t know how to think about it.
I like it when I go "ctrl q" on something in intellij and it shows me what it’s about via a comment.
ask the team lead why they have no comments
Because they decided against it. Their approach is "speaking code".
I can understand that to a point, which is why my default is what it is
I see.
if you think that will impede your success on the team, though, you definitely need to take it into account
if their answer was "we don’t really worry about comments", you could take the approach of leading by example if you join, and see what happens
but "decided against it" suggests that they are actively opposed to comments
The second seems to be the case, that they actively decided that code should "speak by itself", without needing many comments.
like I said, I can understand that to a point
my default is more of "high-leverage comments": add comments where you get a lot of benefit, not just on everything
at least, if other people are seeing the code, or I am concerned about "future me" understanding WTF I just wrote 😁
Yes, we have a "20% comments" rule at work and it goes towards "everything". Sprouts pretty useless comments sometimes.
20% of what? lines of code?
Yes
Every fifth line of code should be a comment :D "should", as it is rarely enforced.
yeah, that feels too far in the overly-verbose direction
The idea is to have comments at all, because before that rule, there were none usually.
I’d rather have a reasonable rule that gets enforced via code reviews
I think the idea behind it is "readable code", but that is a VERY vague rule to enforce ;-)
I had a case of an EditText behaving strangely. It would have the cursor at the very start, even when editing a word inside it, and after going a certain amount of characters the app would crash. Have you ever encountered something like this?
not that I can recall – what was the exception?
Unfortunately I have only the Fragment it’s used in and the layout file it’s defined in.
is there a TextWatcher or something that is attached that might have a bug?
Only some binding.
fun String.toEditable(): Editable = Editable.Factory.getInstance().newEditable(this)
var editText: EditText = binding.yourWord
editText.text = nameGeneratorViewModel.word.toEditable()what’s the point of toEditable()? EditText handles that conversion for you
but, beyond that, you will need to get your hands on a stack trace, I think
There was a problem just doing editText.text = …
Let’s see if I can provoke the error, it was a bit random
btw, when doing this: editText.text = ""
Android Studio says "Type mismatch: inferred type is String but Editable! was expected"
And it’s an "IndexOutOfBoundsException" I’m getting.
java.lang.IndexOutOfBoundsException
at android.graphics.Paint.getRunAdvance(Paint.java:2750)
at android.text.TextLine.getRunAdvance(TextLine.java:845)
at android.text.TextLine.handleText(TextLine.java:894)
at android.text.TextLine.handleRun(TextLine.java:1134)
at android.text.TextLine.measureRun(TextLine.java:528)
at android.text.TextLine.measure(TextLine.java:326)
at android.text.TextLine.metrics(TextLine.java:300)
at android.text.Layout.getLineExtent(Layout.java:1396)
at android.text.Layout.drawText(Layout.java:544)
at android.widget.Editor.drawHardwareAcceleratedInner(Editor.java:1935)
at android.widget.Editor.drawHardwareAccelerated(Editor.java:1854)
at android.widget.Editor.onDraw(Editor.java:1794)
at android.widget.TextView.onDraw(TextView.java:7229)
at android.view.View.draw(View.java:20207)
OK, that’s a rather strange stack trace – are you doing anything strange with the background of this EditText?
No, no background set at all or anything.
<EditText
android:id="@+id/your_word"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_margin="24dp"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toStartOf="@+id/button_save_your_word"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toBottomOf="@+id/generated_word"
android:textAllCaps="true"
android:textSize="20sp"
android:textAlignment="center"
/>remove android:textAllCaps="true" – https://stackoverflow.com/a/61821589/115145
I removed it and it’s still happening. Strange.
Ah, it was in the theme as well.
Removing it there fixed it.
oddly, there does not seem to be an issue tracker item for this
Huh
And did you never stumble over "editText.text = "some string" not working?
I use setText()
I’d rather have EditText do whatever it needs to do to convert the CharSequence, in case I’m missing something
I see. That it explains it.
Thanks for the help finding the EditText bug.
I guess that needs to be done manually now?
Having everything in AllCaps
if by "that", you mean converting the user-entered information into all caps, apparently
The idea was that all the text in the app is in all caps :)
you might need to create an AllCapsEditText that wraps up your solution, then
BUT HAVING A WHOLE APP IN SHOUTY CASE SEEMS LOUD
YES, IT IS, BUT IT LOOKS KINDA OK
I guess creating that is left as an exercise for the reader? ;-)
(the AllCapsEditText
)
there might be one floating around out there
anyway, that’s a wrap for today’s chat
Yes
the next one should be Tuesday in the 7:30pm US Eastern time slot
Thanks for your time
And stay healthy
have a pleasant day!
Same