The Problem:
The built-in Django filter, truncate_words, truncates a string after a certain number of words. This is great, but many times I find I have very tight space restrictions in certain areas of a page, and a string that is too long would push its way into another element and subsequently into my head in the form of a headache.
The built-in truncate_words filter is no help here — it does nothing to limit the width of a string.
I.e., “One two” and “ooooooooooooooooooooooooooonnnnnnnnnnnnnnneeeeeeeeeeeeee twoooooooooooooo” are both only 2 words, yet they have extremely different widths 
The Solution:
We need a filter that truncates not only by words, but by characters too. It’s an extremely simple filter, and often times I wonder why it’s not included in Django.
Let’s start from the very beginning. Every filter must live in your app’s templatetags directory. So create a file in that directory named “truncate_filters.py” or something. If you need any more information than that, take a look at the Django documentation on how to create a custom filter.
Here is what the filter looks like:
from django import template
register = template.Library()
@register.filter("truncate_chars")
def truncate_chars(value, max_length):
if len(value) <= max_length:
return value
truncd_val = value[:max_length]
if value[max_length] != " ":
rightmost_space = truncd_val.rfind(" ")
if rightmost_space != -1:
truncd_val = truncd_val[:rightmost_space]
return truncd_val + "..."
*update* code was changed per chris and paul’s suggestions below, I haven’t tested but assume they work
Here’s how it works visually on this string: “This is a sample string”
This is what happens when the filter is supplied with the argument 20:
- Cut down the string to 20 chars if it is greater than 20 chars in length. The string now becomes: “This is a sample str”
- Find the right-most space, indicating the start of the last word in the string, and truncate again: The string is now: “This is a sample”
- Add “…” and return. “This is a sample…”
You can invoke the filter from within your template like so:
{% load truncate_filters %}
<ol>
{% for some_string in a_list_of_strings %}
<li>{{some_string|truncate_chars:50}}</li>
{% endfor %}
</ol>
Hope someone out there finds this helpful
The Dark Side of Code Commenting
Ever since the beginning of my journey to become a solid programmer, it was taught to me that commenting code was always a good thing. You can never have enough comments, they would say. The golden rule was to have at least an equal comments to code line ratio.
All of this made sense to me back in college. Nothing wrong with being too descriptive right? Wrong! Sure, comments can be a great thing. There’s nothing better than reading a comment that helps you understand some complex piece of code. However, after working in the industry for awhile, I’ve seen the dark side of comments.
The other day, while working on one of many bugfixes, I came across an obfuscated piece of code. Instead of diving into it and figuring out where each function/variable/whatever came from, I trusted a couple lines of comments above the code. Thank god for comments, right! Wrong again! Apparently, whoever wrote that code wrote it over someone else’s code, but hadn’t updated the comment because he hadn’t noticed it. So the comment was downright false. A lie. Imagine dealing with that all day. Ever try to understand thousands of lines of code where some comments are leading you down the wrong path, like satan?
My thinking is, keep the comments to a minimum. Instead of commenting excessively, try to write your code in such a way that it doesn’t *need* too many comments to understand. Good code speaks for itself
And don’t be lazy, always update the comments as needed as your code changes. If you come across a useless one, throw it out… like a leper!
Because I’ve been getting some weird feedback on this post (my fault most likely, for being a professional programmer and not a writer), let me reiterate my point here…comments, when used appropriately, are a good thing! The key word is appropriately. Don’t diarrhea all over your code. It’s stinky. And too many people do it. When a developer sees a piece of code, he tries to understand. When he reads a comment, he is inclined to believe it right off the bat. So don’t mess with his head. Get it?
Oh and hey, leave some “comments” below if you’ve had bad experiences too